idnits 2.17.1 draft-ietf-forces-protocol-13.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 23. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 5125. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 5136. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 5143. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 5149. 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 the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 'NoACK' (0b00) - to indicate that the message receiver MUST not send any response message back to this message sender. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 4, 2007) is 5986 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 1813, but not defined == Missing Reference: 'SELECTOR' is mentioned on line 1814, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'FE-MODEL' ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 2 errors (**), 0 flaws (~~), 6 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: June 6, 2008 IBM 6 J. Hadi Salim (Ed.) 7 Znyx 8 H. Khosravi (Ed.) 9 Intel 10 W. M. Wang (Ed.) 11 Zhejiang Gongshang University 13 December 4, 2007 15 ForCES Protocol Specification 16 draft-ietf-forces-protocol-13.txt 18 Status of this Memo 20 By submitting this Internet-Draft, each author represents that any 21 applicable patent or other IPR claims of which he or she is aware 22 have been or will be disclosed, and any of which he or she becomes 23 aware will be disclosed, in accordance with Section 6 of BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF), its areas, and its working groups. Note that 27 other groups may also distribute working documents as Internet- 28 Drafts. 30 Internet-Drafts are draft documents valid for a maximum of six months 31 and may be updated, replaced, or obsoleted by other documents at any 32 time. It is inappropriate to use Internet-Drafts as reference 33 material or to cite them other than as "work in progress." 35 The list of current Internet-Drafts can be accessed at 36 http://www.ietf.org/ietf/1id-abstracts.txt. 38 The list of Internet-Draft Shadow Directories can be accessed at 39 http://www.ietf.org/shadow.html. 41 This Internet-Draft will expire on June 6, 2008. 43 Copyright Notice 45 Copyright (C) The IETF Trust (2007). 47 Abstract 49 This document specifies the Forwarding and Control Element Separation 50 (ForCES) protocol. ForCES protocol is used for communications 51 between Control Elements(CEs) and Forwarding Elements (FEs) in a 52 ForCES Network Element (ForCES NE). This specification is intended 53 to meet the ForCES protocol requirements defined in RFC3654. Besides 54 the ForCES protocol messages, the specification also defines the 55 framework, the mechanisms, and the Transport Mapping Layer (TML) 56 requirements for ForCES protocol. 58 Authors 60 The participants in the ForCES Protocol Team, primary co-authors and 61 co-editors, of this protocol specification, are: 63 Ligang Dong (Zhejiang Gongshang University), Avri Doria (Lulea 64 University of Technology), Ram Gopal (Nokia), Robert Haas (IBM), 65 Jamal Hadi Salim (Znyx), Hormuzd M Khosravi (Intel), and Weiming Wang 66 (Zhejiang Gongshang University). Special acknowledgement goes to 67 Joel Halpern whose has done extensive editing in support of 68 congruence between the model and this protocol specification. 69 Without his participation and persistence, this specification might 70 never have been completed. 72 Table of Contents 74 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 6 75 1.1. 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 152 Appendix A. IANA Considerations . . . . . . . . . . . . . . . . 92 153 A.1. Message Type Name Space . . . . . . . . . . . . . . . . . 92 154 A.2. Operation Selection . . . . . . . . . . . . . . . . . . . 93 155 A.3. Header Flags . . . . . . . . . . . . . . . . . . . . . . 94 156 A.4. TLV Type Name Space . . . . . . . . . . . . . . . . . . . 94 157 A.5. Result-TLV Result Values . . . . . . . . . . . . . . . . 94 158 A.6. Association Setup Response . . . . . . . . . . . . . . . 95 159 A.7. Association Teardown Message . . . . . . . . . . . . . . 96 160 Appendix B. ForCES Protocol LFB schema . . . . . . . . . . . . . 97 161 B.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 102 162 B.2. Components . . . . . . . . . . . . . . . . . . . . . . . 103 163 Appendix C. Data Encoding Examples . . . . . . . . . . . . . . . 104 164 Appendix D. Use Cases . . . . . . . . . . . . . . . . . . . . . 108 165 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 123 166 Intellectual Property and Copyright Statements . . . . . . . . . 125 168 1. Terminology and Conventions 170 The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, 171 RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted 172 as described in BCP 14, RFC2119 [RFC2119]. 174 1.1. Other Notation 176 In table Table 1 and table Table 2 the following notation is used to 177 indicate multiplicity: 179 (value)+ .... means "1 or more instance of value" 181 (value)* .... means "0 or more instance of value" 183 2. Introduction 185 Forwarding and Control Element Separation (ForCES) defines an 186 architectural framework and associated protocols to standardize 187 information exchange between the control plane and the forwarding 188 plane in a ForCES Network Element (ForCES NE). RFC 3654 has defined 189 the ForCES requirements, and RFC 3746 has defined the ForCES 190 framework. While there may be multiple protocols used within the 191 overall ForCES architecture, the term "ForCES protocol" and 192 "protocol" as used in this document refers to the protocol used to 193 standardize the information exchange between Control Elements (CEs) 194 and Forwarding Elements (FEs) only. 196 The ForCES FE model [FE-MODEL] presents a formal way to define FE 197 Logical Function Blocks (LFBs) using XML. LFB configuration 198 components, capabilities, and associated events are defined when the 199 LFB is formally created. The LFBs within the FE are accordingly 200 controlled in a standardized way by the ForCES protocol. 202 This document defines the ForCES protocol specifications. The ForCES 203 protocol works in a master-slave mode in which FEs are slaves and CEs 204 are masters. The protocol includes commands for transport of Logical 205 Function Block(LFB) configuration information, association setup, 206 status, and event notifications, etc. 208 This specification does not define a transport mechanism for protocol 209 messages. A discussion of service primitives that must be provided 210 by the underlying transport interface will be discussed in a future 211 document. 213 Section 3 provides a glossary of terminology used in the 214 specification. 216 Section 4 provides an overview of the protocol, including a 217 discussion on the protocol framework, descriptions of the Protocol 218 Layer (PL) and a Transport Mapping Layer (TML), as well as of the 219 ForCES protocol mechanisms. Section 4.4 describes several Protocol 220 scenarios and includes message exchange descriptions. 222 While this document does not define the TML, Section 5 details the 223 services that a TML must provide (TML requirements). 225 The ForCES protocol defines a common header for all protocol 226 messages. The header is defined in Section 6.1, while the protocol 227 messages are defined in Section 7. 229 Section 8 describes the protocol support for high availability 230 mechanisms including redundancy and fail over. 232 Section 9 defines the security mechanisms provided by the PL and TML. 234 3. Definitions 236 This document follows the terminology defined by the ForCES 237 Requirements in [RFC3654] and by the ForCES framework in [RFC3746]. 238 The definitions below are repeated below for clarity. 240 Addressable Entity (AE) - A physical device that is directly 241 addressable given some interconnect technology. For example, on IP 242 networks, it is a device which can be reached using an IP address; 243 and on a switch fabric, it is a device which can be reached using a 244 switch fabric port number. 246 Control Element (CE) - A logical entity that implements the ForCES 247 protocol and uses it to instruct one or more FEs on how to process 248 packets. CEs handle functionality such as the execution of control 249 and signaling protocols. 251 CE Manager (CEM) - A logical entity responsible for generic CE 252 management tasks. It is particularly used during the pre-association 253 phase to determine with which FE(s) a CE should communicate. This 254 process is called FE discovery and may involve the CE manager 255 learning the capabilities of available FEs. 257 Datapath - A conceptual path taken by packets within the forwarding 258 plane inside an FE. 260 Forwarding Element (FE) - A logical entity that implements the ForCES 261 protocol. FEs use the underlying hardware to provide per-packet 262 processing and handling as directed/controlled by one or more CEs via 263 the ForCES protocol. 265 FE Model - A model that describes the logical processing functions of 266 an FE. The FE model is defined using Logical Function Blocks (LFBs). 268 FE Manager (FEM) - A logical entity responsible for generic FE 269 management tasks. It is used during pre-association phase to 270 determine with which CE(s) an FE should communicate. This process is 271 called CE discovery and may involve the FE manager learning the 272 capabilities of available CEs. An FE manager may use anything from a 273 static configuration to a pre-association phase protocol (see below) 274 to determine which CE(s) to use. Being a logical entity, an FE 275 manager might be physically combined with any of the other logical 276 entities such as FEs. 278 ForCES Network Element (NE) - An entity composed of one or more CEs 279 and one or more FEs. To entities outside an NE, the NE represents a 280 single point of management. Similarly, an NE usually hides its 281 internal organization from external entities. 283 High Touch Capability - This term will be used to apply to the 284 capabilities found in some forwarders to take action on the contents 285 or headers of a packet based on content other than what is found in 286 the IP header. Examples of these capabilities include NAT-PT, 287 firewall, and L7 content recognition. 289 Inter-FE Topology - See FE Topology. 291 Intra-FE Topology - See LFB Topology. 293 LFB (Logical Function Block) - The basic building block that is 294 operated on by the ForCES protocol. The LFB is a well defined, 295 logically separable functional block that resides in an FE and is 296 controlled by the CE via ForCES protocol. The LFB may reside at the 297 FE's datapath and process packets or may be purely an FE control or 298 configuration entity that is operated on by the CE. Note that the 299 LFB is a functionally accurate abstraction of the FE's processing 300 capabilities, but not a hardware-accurate representation of the FE 301 implementation. 303 FE Topology - A representation of how the multiple FEs within a 304 single NE are interconnected. Sometimes this is called inter-FE 305 topology, to be distinguished from intra-FE topology (i.e., LFB 306 topology). 308 LFB Class and LFB Instance - LFBs are categorized by LFB Classes. An 309 LFB Instance represents an LFB Class (or Type) existence. There may 310 be multiple instances of the same LFB Class (or Type) in an FE. An 311 LFB Class is represented by an LFB Class ID, and an LFB Instance is 312 represented by an LFB Instance ID. As a result, an LFB Class ID 313 associated with an LFB Instance ID uniquely specifies an LFB 314 existence. 316 LFB Metadata - Metadata is used to communicate per-packet state from 317 one LFB to another, but is not sent across the network. The FE model 318 defines how such metadata is identified, produced and consumed by the 319 LFBs. It defines the functionality but not how metadata is encoded 320 within an implementation. 322 LFB Attribute - Operational parameters of the LFBs that must be 323 visible to the CEs are conceptualized in the FE model as the LFB 324 attributes. The LFB attributes include, for example, flags, single 325 parameter arguments, complex arguments, and tables that the CE can 326 read and/or write via the ForCES protocol (see below). 328 LFB Topology - Representation of how the LFB instances are logically 329 interconnected and placed along the datapath within one FE. 330 Sometimes it is also called intra-FE topology, to be distinguished 331 from inter-FE topology. 333 Pre-association Phase - The period of time during which an FE Manager 334 and a CE Manager are determining which FE(s) and CE(s) should be part 335 of the same network element. 337 Post-association Phase - The period of time during which an FE knows 338 which CE is to control it and vice versa. This includes the time 339 during which the CE and FE are establishing communication with one 340 another. 342 ForCES Protocol - While there may be multiple protocols used within 343 the overall ForCES architecture, the term "ForCES protocol" and 344 "protocol" refer to the Fp reference point in the ForCES Framework in 345 [RFC3746]. This protocol does not apply to CE-to-CE communication, 346 FE-to-FE communication, or to communication between FE and CE 347 managers. Basically, the ForCES protocol works in a master-slave 348 mode in which FEs are slaves and CEs are masters. This document 349 defines the specifications for this ForCES protocol. 351 ForCES Protocol Layer (ForCES PL) - A layer in ForCES protocol 352 architecture that defines the ForCES protocol messages, the protocol 353 state transfer scheme, as well as the ForCES protocol architecture 354 itself (including requirements of ForCES TML as shown below). 355 Specifications of ForCES PL are defined by this document. 357 ForCES Protocol Transport Mapping Layer (ForCES TML) - A layer in 358 ForCES protocol architecture that uses the capabilities of existing 359 transport protocols to specifically address protocol message 360 transportation issues, such as how the protocol messages are mapped 361 to different transport media (like TCP, IP, ATM, Ethernet, etc), and 362 how to achieve and implement reliability, multicast, ordering, etc. 363 The ForCES TML specifications are detailed in separate ForCES 364 documents, one for each TML. 366 4. Overview 368 The reader is referred to the Framework document [RFC3746], and in 369 particular sections 3 and 4, for an architectural overview and an 370 explanation of how the ForCES protocol fits in. There may be some 371 content overlap between the framework document and this section in 372 order to provide clarity. This document is authoritative on the 373 protocol whereas [RFC3746] is authoritative on the architecture. 375 4.1. Protocol Framework 377 Figure 1 below is reproduced from the Framework document for clarity. 378 It shows a NE with two CEs and two FEs. 380 --------------------------------------- 381 | ForCES Network Element | 382 -------------- Fc | -------------- -------------- | 383 | CE Manager |---------+-| CE 1 |------| CE 2 | | 384 -------------- | | | Fr | | | 385 | | -------------- -------------- | 386 | Fl | | | Fp / | 387 | | Fp| |----------| / | 388 | | | |/ | 389 | | | | | 390 | | | Fp /|----| | 391 | | | /--------/ | | 392 -------------- Ff | -------------- -------------- | 393 | FE Manager |---------+-| FE 1 | Fi | FE 2 | | 394 -------------- | | |------| | | 395 | -------------- -------------- | 396 | | | | | | | | | | 397 ----+--+--+--+----------+--+--+--+----- 398 | | | | | | | | 399 | | | | | | | | 400 Fi/f Fi/f 402 Fp: CE-FE interface 403 Fi: FE-FE interface 404 Fr: CE-CE interface 405 Fc: Interface between the CE Manager and a CE 406 Ff: Interface between the FE Manager and an FE 407 Fl: Interface between the CE Manager and the FE Manager 408 Fi/f: FE external interface 410 Figure 1: ForCES Architectural Diagram 412 The ForCES protocol domain is found in the Fp Reference Point. The 413 Protocol Element configuration reference points, Fc and Ff also play 414 a role in the booting up of the ForCES Protocol. The protocol 415 element configuration (indicated by reference points Fc, Ff, and Fl 416 in [RFC3746] ) is out of scope of the ForCES protocol but is touched 417 on in this document in discussion of FEM and CEM since it is an 418 integral part of the protocol pre-association phase. 420 Figure 2 below shows further breakdown of the Fp interface by example 421 of an MPLS QoS enabled Network Element. 423 ------------------------------------------------- 424 | | | | | | | 425 |OSPF |RIP |BGP |RSVP |LDP |. . . | 426 | | | | | | | 427 ------------------------------------------------- CE 428 | ForCES Interface | 429 ------------------------------------------------- 430 ^ ^ 431 | | 432 ForCES | |data 433 control | |packets 434 messages| |(e.g., routing packets) 435 | | 436 v v 437 ------------------------------------------------- 438 | ForCES Interface | 439 ------------------------------------------------- FE 440 | | | | | | | 441 |LPM Fwd|Meter |Shaper |MPLS |Classi-|. . . | 442 | | | | |fier | | 443 ------------------------------------------------- 445 Figure 2: Examples of CE and FE functions 447 The ForCES Interface shown in Figure 2 constitutes two pieces: the PL 448 and the TML. 450 This is depicted in Figure 3 below. 452 +------------------------------------------------ 453 | CE PL | 454 +------------------------------------------------ 455 | CE TML | 456 +------------------------------------------------ 457 ^ 458 | 459 ForCES | (i.e ForCES data + control 460 PL | packets ) 461 messages | 462 over | 463 specific | 464 TML | 465 encaps | 466 and | 467 transport | 468 | 469 v 470 +------------------------------------------------ 471 | FE TML | 472 +------------------------------------------------ 473 | FE PL | 474 +------------------------------------------------ 476 Figure 3: ForCES Interface 478 The PL is in fact the ForCES protocol. Its semantics and message 479 layout are defined in this document. The TML Layer is necessary to 480 connect two ForCES PLs as shown in Figure 3 above. The TML is out of 481 scope for this document but is within scope of ForCES. This document 482 defines requirements the PL needs the TML to meet. 484 Both the PL and the TML are standardized by the IETF. While only one 485 PL is defined, different TMLs are expected to be standardized. To 486 interoperate the TML at the CE and FE are expected to conform to the 487 same definition. 489 On transmit, the PL delivers its messages to the TML. The local TML 490 delivers the message to the destination TML. On receive, the TML 491 delivers the message to its destination PL. 493 4.1.1. The PL 495 The PL is common to all implementations of ForCES and is standardized 496 by the IETF as defined in this document. The PL is responsible for 497 associating an FE or CE to an NE. It is also responsible for tearing 498 down such associations. An FE uses the PL to transmit various 499 subscribed-to events to the CE PL as well as to respond to various 500 status requests issued from the CE PL. The CE configures both the FE 501 and associated LFBs' operational parameters using the PL. In 502 addition the CE may send various requests to the FE to activate or 503 deactivate it, reconfigure its HA parameterization, subscribe to 504 specific events etc. More details can be found in Section 7. 506 4.1.2. The TML 508 The TML transports the PL messages. The TML is where the issues of 509 how to achieve transport level reliability, congestion control, 510 multicast, ordering, etc. are handled. It is expected that more than 511 one TML will be standardized. The various possible TMLs could vary 512 their implementations based on the capabilities of underlying media 513 and transport. However, since each TML is standardized, 514 interoperability is guaranteed as long as both endpoints support the 515 same TML. All ForCES Protocol Layer implementations MUST be portable 516 across all TMLs, because all TMLs MUST have the top edge semantics 517 defined in this document. 519 4.1.3. The FEM/CEM Interface 521 The FEM and CEM components, although valuable in the setup and 522 configurations of both the PL and TML, are out of scope of the ForCES 523 protocol. The best way to think of them is as configurations/ 524 parameterizations for the PL and TML before they become active (or 525 even at runtime based on implementation). In the simplest case, the 526 FE or CE reads a static configuration file. RFC 3746 has a more 527 detailed description on how the FEM and CEM could be used. The pre- 528 association phase, where the CEM and FEM can be used, are described 529 briefly in Section 4.2.1. 531 An example of typical things the FEM/CEM could configure would be TML 532 specific parameterizations such as: 534 a. How the TML connection should happen (for example what IP 535 addresses to use, transport modes etc); 537 b. The ID for the FE or CE (which would also be issued during the 538 pre-association phase). 540 c. Security parameterization such as keys etc. 542 d. Connection association parameters 544 Example of connection association parameters this might be: 546 o simple parameters: send up to 3 association messages every 1 547 second 549 o complex parameters: send up to 4 association messages with 550 increasing exponential timeout 552 4.2. ForCES Protocol Phases 554 ForCES, in relation to NEs, involves two phases: the Pre-Association 555 phase, where configuration/initialization/bootup of the TML and PL 556 layer happens, and the association phase where the ForCES protocol 557 operates to manipulate the parameters of the FEs. 559 CE sends Association Setup 560 +---->--->------------>---->---->---->------->----+ 561 | Y 562 ^ | 563 | Y 564 +---+-------+ +-------------+ 565 |FE Pre- | | FE | 566 |Association| CE sends Association Teardown | Associated | 567 |Phase |<------- <------<-----<------<-------+ | 568 | | | | 569 +-----------+ +-------------+ 570 ^ Y 571 | | 572 +-<---<------<-----<------<----<---------<------+ 573 FE loses association 575 Figure 4: The FE State Machine 577 In the mandated case, once associated, the FE may forward packets 578 depending on the configuration of its specific LFBs. An FE which is 579 associated to a CE will continue sending packets until it receives an 580 Association teardown message or until it loses association. An 581 unassociated FE MAY continue sending packets when it is capable high 582 availability. The extra details are explained in Section 8 and not 583 discussed here to allow for a clear explanation of the basics. 585 The CE configures FE state transitions by means of the FE Object LFB, 586 which is defined in [FE-MODEL] and also explained in Section 7.3.2. 587 In the FE Object LFB, FE state is defined as an attribute of the LFB, 588 and CE configuration of the FE state equals CE configuration of this 589 attribute. Note that even in the FE DOWN state, the FE is 590 associated. 592 The FE stays in the DOWN state until it is explicitly configured by 593 the CE to transition to the UP state via an FE Object admin action. 594 This must be done before configuring any other LFBs that affect 595 packet forwarding. The typical setup will bring up the FE to the UP 596 state on association. 598 The FE transitions from the UP state to the DOWN state when it 599 receives an FEObject Admin Down action. when it loses its association 600 with the CE it may go into the pre-association phase depending on the 601 programmed policy. For the FE to properly complete the transition to 602 the DOWN state, it MUST stop Packet forwarding and this may impact 603 multiple LFBS. How this is achieved is outside the scope of this 604 specification. 606 4.2.1. Pre-association 608 The ForCES interface is configured during the pre-association phase. 609 In a simple setup, the configuration is static and is read from a 610 saved configuration file. All the parameters for the association 611 phase are well known after the pre-association phase is complete. A 612 protocol such as DHCP may be used to retrieve the configuration 613 parameters instead of reading them from a static configuration file. 614 Note, this will still be considered static pre-association. Dynamic 615 configuration may also happen using the Fc, Ff and Fl reference 616 points (refer to [RFC3746]). Vendors may use their own proprietary 617 service discovery protocol to pass the parameters. Essentially, only 618 guidelines are provided here and the details are left to the 619 implementation. 621 The following are scenarios reproduced from the Framework Document to 622 show a pre-association example. 624 <----Ff ref pt---> <--Fc ref pt-------> 625 FE Manager FE CE Manager CE 626 | | | | 627 | | | | 628 (security exchange) (security exchange) 629 1|<------------>| authentication 1|<----------->|authentication 630 | | | | 631 (FE ID, components) (CE ID, components) 632 2|<-------------| request 2|<------------|request 633 | | | | 634 3|------------->| response 3|------------>|response 635 (corresponding CE ID) (corresponding FE ID) 636 | | | | 637 | | | | 639 Figure 5: Examples of a message exchange over the Ff and Fc reference 640 points 642 <-----------Fl ref pt--------------> | 644 FE Manager FE CE Manager CE 645 | | | | 646 | | | | 647 (security exchange) | | 648 1|<------------------------------>| | 649 | | | | 650 (a list of CEs and their components) | 651 2|<-------------------------------| | 652 | | | | 653 (a list of FEs and their components) | 654 3|------------------------------->| | 655 | | | | 656 | | | | 658 Figure 6: An example of a message exchange over the Fl reference 659 point 661 Before the transition to the association phase, the FEM will have 662 established contact with a CEM component. Initialization of the 663 ForCES interface will have completed, and authentication as well as 664 capability discovery may be complete. Both the FE and CE would have 665 the necessary information for connecting to each other for 666 configuration, accounting, identification, and authentication 667 purposes. To summarize, at the completion of this stage both sides 668 have all the necessary protocol parameters such as timers, etc. The 669 Fl reference point may continue to operate during the association 670 phase and may be used to force a disassociation of an FE or CE. 671 Because the pre-association phase is out of scope, these details are 672 not discussed any further in this specification. The reader is 673 referred to the framework document [RFC3746] for a slightly more 674 detailed discussion. 676 4.2.2. Post-association 678 In this phase, the FE and CE components communicate with each other 679 using the ForCES protocol (PL over TML) as defined in this document. 680 There are three sub-phases: 682 o Association Setup Stage 684 o Established Stage 685 o Association Lost Stage 687 4.2.2.1. Association Setup Stage 689 The FE attempts to join the NE. The FE may be rejected or accepted. 690 Once granted access into the NE, capabilities exchange happens with 691 the CE querying the FE. Once the CE has the FE capability 692 information, the CE can offer an initial configuration (possibly to 693 restore state) and can query certain components within either an LFB 694 or the FE itself. 696 More details are provided in Section 4.4. 698 On successful completion of this stage, the FE joins the NE and is 699 moved to the Established Stage. 701 4.2.2.2. Established Stage 703 In this stage, the FE is continuously updated or queried. The FE may 704 also send asynchronous event notifications to the CE or synchronous 705 heartbeat notifications if programmed to do so. This stage continues 706 until a termination occurs, either due to loss of connectivity or due 707 to a termination initiated by either the CE or the FE. 709 Refer to the section on protocol scenarios, Section 4.4, for more 710 details. 712 4.2.2.3. Association Lost Stage 714 In this state, both or either the CE or FE declare the other side is 715 no longer associated. The disconnection could be initiated by either 716 party for administrative purposes but may also be driven by 717 operational reasons such as loss of connectivity. 719 A core LFB known as FE Protocol Object (FEPO) is defined (refer to 720 Appendix B and Section 7.3.1). FEPO defines various timers which can 721 be used in conjunction with traffic sensitive heartbeat mechanism 722 (Section 4.3.3) to detect loss of connectivity. 724 The loss of connectivity between TMLs does not indicate a loss of 725 association between respective PL layers. If the TML cannot repair 726 the transport loss before the programmed FEPO timer thresholds 727 associated with the FE is exceeded, then the association between the 728 respective PL layers will be lost. 730 FEPO defines several policies that can be programmed to define 731 behavior upon a detected loss of association. The FEPO's programmed 732 CE failover policy (refer to Section 8, Section 7.3.1, Section 4.3.3 733 and Appendix B) defines what takes place upon loss of association. 735 For this version of the protocol (as defined in this document), the 736 FE, upon re-association, MUST discard any state it has as invalid and 737 retrieve new state. This approach is motivated by a desire for 738 simplicity (as opposed to efficiency). 740 4.3. Protocol Mechanisms 742 Various semantics are exposed to the protocol users via the PL header 743 including: transaction capabilities, atomicity of transactions, two 744 phase commits, batching/parallelization, high availability and 745 failover as well as command pipelines. 747 The EM (Execute Mode) flag, AT (Atomic Transaction) flag, and TP 748 (Transaction Phase) flag as defined in the Common Header 749 (Section 6.1) are relevant to these mechanisms. 751 4.3.1. Transactions, Atomicity, Execution and Responses 753 In the master-slave relationship the CE instructs one or more FEs on 754 how to execute operations and how to report the results. 756 This section details the different modes of execution that a CE can 757 order the FE(s) to perform, as defined in Section 4.3.1.1. It also 758 describes the different modes a CE can ask the FE(s) to use for 759 formatting the responses after processing the operations as 760 requested. These modes relate to the transactional two phase 761 commitment operations. 763 4.3.1.1. Execution 765 There are 3 execution modes that can be requested for a batch of 766 operations spanning one or more LFB selectors (refer to 767 Section 7.1.5) in one protocol message. The EM flag defined in the 768 Common Header Section 6.1 selects the execution mode for a protocol 769 message, as below: 771 a. execute-all-or-none 773 b. execute-until-failure 775 c. continue-execute-on-failure 777 4.3.1.1.1. execute-all-or-none 779 When set to this mode of execution, independent operations in a 780 message MAY be targeted at one or more LFB selectors within an FE. 781 All these operations are executed serially and the FE MUST have no 782 execution failure for any of the operations. If any operation fails 783 to execute, then all the previous ones that have been executed prior 784 to the failure will need to be undone. I.e., there is rollback for 785 this mode of operation. 787 Refer to Section 4.3.1.2.2 for how this mode is used in cases of 788 transactions. In such a case, no operation is executed unless a 789 commit is issued by the CE. 791 Care should be taken on how this mode is used because a mis- 792 configuration could result in traffic losses. To add certainty to 793 the success of an operation, one should use this mode in a 794 transactional operation as described in Section 4.3.1.2.2 796 4.3.1.1.2. continue-execute-on-failure 798 If several independent operations are targeted at one or more LFB 799 selectors, execution continues for all operations at the FE even if 800 one or more operations fail. 802 4.3.1.1.3. execute-until-failure 804 In this mode all operations are executed on the FE sequentially until 805 the first failure. The rest of the operations are not executed but 806 operations already completed are not undone. I.e., there is no 807 rollback in this mode of operation. 809 4.3.1.2. Transaction and Atomicity 811 4.3.1.2.1. Transaction Definition 813 A transaction is defined as a collection of one or more ForCES 814 operations within one or more PL messages that MUST meet the ACIDity 815 properties [ACID], defined as: 817 Atomicity: In a transaction involving two or more discrete pieces 818 of information, either all of the pieces are committed 819 or none are. 821 Consistency: A transaction either creates a new and valid state of 822 data, or, if any failure occurs, returns all data to the 823 state it was in before the transaction was started. 825 Isolation: A transaction in process and not yet committed must 826 remain isolated from any other transaction. 828 Durability: Committed data is saved by the system such that, even in 829 the event of a failure and a system restart, the data is 830 available in its correct state. 832 There are cases where the CE knows exact memory and implementation 833 details of the FE such as in the case of an FE-CE pair from the same 834 vendor where the FE-CE pair is tightly coupled. In such a case, the 835 transactional operations may be simplified further by extra 836 computation at the CE. This view is not discussed further other than 837 to mention that it is not disallowed. 839 As defined above, a transaction is always atomic and MAY be 841 a. Within an FE alone 842 Example: updating multiple tables that are dependent on each 843 other. If updating one fails, then any that were already updated 844 must be undone. 846 b. Distributed across the NE 847 Example: updating table(s) that are inter-dependent across 848 several FEs (such as L3 forwarding related tables). 850 4.3.1.2.2. Transaction Protocol 852 By use of the execute mode, as defined in Section 4.3.1.1, the 853 protocol has provided a mechanism for transactional operations within 854 one stand-alone message. The 'execute-all-or-none' mode can meet the 855 ACID requirements. 857 For transactional operations of multiple messages within one FE or 858 across FEs, a classical transactional protocol known as Two Phase 859 Commit (2PC) [2PCREF] is supported by the protocol to achieve the 860 transactional operations utilizing Config messages (Section 7.6.1). 862 The COMMIT and TRCOMP operations in conjunction with the AT and the 863 TP flags in Common Header (Section 6.1) are provided for 2PC-based 864 transactional operations spanning multiple messages. 866 The AT flag, when set, indicates this message belongs to an Atomic 867 Transaction. All messages for a transaction operation must have the 868 AT flag set. If not set, it means the message is a stand-alone 869 message and does not participate in any transaction operation that 870 spans multiple messages. 872 The TP flag indicates the Transaction Phase this message belongs to. 874 There are four (4) possible phases for an transactional operation 875 known as: 877 SOT (Start of Transaction) 879 MOT (Middle of Transaction) 881 EOT (End of Transaction) 883 ABT (Abort) 885 The COMMIT operation is used by the CE to signal to the FE(s) to 886 commit a transaction. When used with an ABT TP flag, the COMMIT 887 operation signals the FE(s) to rollback (i.e un-COMMIT) a previously 888 committed transaction. 890 The TRCOMP operation is a small addition to the classical 2PC 891 approach. TRCOMP is sent by the CE to signal the FE(s) that the 892 transaction they have COMMITed is now over. This allows the FE(s) an 893 opportunity to clear state they may have kept around to perform a 894 rollback (if it became necessary). 896 A transaction operation is started with a message the TP flag is set 897 to Start of Transaction (SOT). Multi-part messages, after the first 898 one, are indicated by the Middle of Transaction flag (MOT). All 899 messages from the CE MUST set the AlwaysACK flag (Section 6) to 900 solicit responses from the FE(s). 902 Before the CE issues a commit (described further below) the FE MUST 903 only validate that the operation can be executed but not execute it. 905 Any failure notified by an FE causes the CE to abort the 906 transaction on all FEs involved in the transaction. This is 907 achieved by sending a Config message with an ABT flag and a COMMIT 908 operation. 910 If there are no failures by any participating FE, the transaction 911 commitment phase is signaled from the CE to the FE by an End of 912 Transaction (EOT) configuration message with a COMMIT operation. 914 The FE MUST respond to the CE's EOT message. There are two possible 915 failure scenarios in which the CE MUST abort the transaction (as 916 described above): 918 a. If any participating FE responds with a failure message in 919 relation to the transaction. 921 b. If no response is received from a participating FE within a 922 specified timeout. 924 If all participating FE(s) respond with a success indicator within 925 the expected time, then the CE MUST issue a TRCOMP operation to all 926 participating FEs. An FE MUST NOT respond to a TRCOMP. 928 Note that a transactional operation is generically atomic, therefore 929 it requires that the execute modes of all messages in a transaction 930 operation should always be kept the same and be set to 'execute-all- 931 or-none'. If the EM flag is set to other execute modes, it will 932 result in a transaction failure. 934 As noted above, a transaction may span multiple messages. It is up 935 to the CE to keep track of the different outstanding messages making 936 up a transaction. As an example, the correlator field could be used 937 to mark transactions and a sequence field to label the different 938 messages within the same atomic transaction, but this is out of scope 939 and up to implementations. 941 4.3.1.2.3. Recovery 943 Any of the participating FEs, or the CE, or the associations between 944 them, may fail after the EOT response message has been sent by the FE 945 but before the CE has received all the responses, e.g. if the EOT 946 response never reaches the CE. 948 In this protocol revision, as indicated in Section 4.2.2.3, an FE 949 losing an association would be required to get entirely new state 950 from the newly associated CE upon a re-association. Although this 951 approach is simplistic and provides likeliness of loosing datapath 952 traffic, it is a design choice to avoid the additional complexity of 953 managing graceful restarts. The HA mechanisms (Section 8) are 954 provided to allow for a continuous operation in case of FE failures. 956 Flexibility is provided on how to react when an FE looses 957 association. This is dictated by the CE Failover policy (refer to 958 Section 8 and Section 7.3). 960 4.3.1.2.4. Transaction Messaging Example 962 This section illustrates an example of how a successful two phase 963 commit between a CE and an FE would look like in the simple case. 965 FE PL CE PL 967 | | 968 | (1) Config, SOT,AT, EM=All-or-None, OP= SET/DEL,etc | 969 |<-----------------------------------------------------| 970 | | 971 | (2) ACKnowledge | 972 |----------------------------------------------------->| 973 | | 974 | (3) Config, MOT,AT, EM=All-or-None, OP= SET/DEL,etc | 975 |<-----------------------------------------------------| 976 | | 977 | (4) ACKnowledge | 978 |----------------------------------------------------->| 979 | | 980 | (5) Config, MOT,AT, EM=All-or-None, OP= SET/DEL,etc | 981 |<-----------------------------------------------------| 982 | | 983 | (6) ACKnowledge | 984 |----------------------------------------------------->| 985 . . 986 . . 987 . . 988 . . 989 | | 990 | (N) Config, EOT,AT, EM=All-or-None, OP= COMMIT | 991 |<-----------------------------------------------------| 992 | | 993 | (N+1)Config-response, ACKnowledge, OP=COMMIT-RESPONSE| 994 |----------------------------------------------------->| 995 | | 996 | (N+2) Config, OP=TRCOMP | 997 |<-----------------------------------------------------| 999 Figure 7: Example of a two phase commit 1001 For the scenario illustrated above: 1003 o In step #1, the CE issues a Config message with an operation of 1004 choice like a DEL or SET. The transactional flag are set to 1005 indicate a Start of Transaction (SOT), Atomic Transaction (AT), 1006 execute-all-or-none. 1008 o The FE validates that it can execute the request successfully and 1009 then issues an acknowledgment back to the the CE in step #2. 1011 o In step #3, the same sort of construct as in step #1 is repeated 1012 by the CE with the transaction flag changed to Middle of 1013 Transaction(MOT). 1015 o The FE validates that it can execute the request successfully and 1016 then issues an acknowledgment back to the the CE in step #4. 1018 o The CE-FE exchange continues in the same manner until all the 1019 operations and their parameters are transferred to the FE. This 1020 happens in step #(N-1). 1022 o In step #N, the CE issues a commit. A commit is a config message 1023 with an operation of type COMMIT. The transactional flags are set 1024 to End of Transaction (EOT). Essentially, this is an "empty" 1025 message asking the FE to execute all the operations it has 1026 gathered since the beginning of the transaction (message #1). 1028 o The FE at this point executes the full transaction. It then 1029 issues an acknowledgment back to the the CE in step #(N+1) which 1030 contains a COMMIT-RESPONSE. 1032 o The CE in this case has the simple task of issuing a TRCOMP 1033 operation the the FE in step #(N+2) 1035 4.3.2. Scalability 1037 It is desirable that the PL not become the bottleneck when larger 1038 bandwidth pipes become available. To pick a hypothetical example in 1039 today's terms, if a 100Gbps pipe is available and there is sufficient 1040 work then the PL should be able to take advantage of this and use all 1041 of the 100Gbps pipe. Two mechanisms have been provided to achieve 1042 this. The first one is batching and the second one is a command 1043 pipeline. 1045 Batching is the ability to send multiple commands (such as Config) in 1046 one Protocol Data Unit (PDU). The size of the batch will be affected 1047 by, amongst other things, the path MTU. The commands may be part of 1048 the same transaction or may be part of unrelated transactions that 1049 are independent of each other. 1051 Command pipelining allows for pipelining of independent transactions 1052 which do not affect each other. Each independent transaction could 1053 consist of one or more batches. 1055 4.3.2.1. Batching 1057 There are several batching levels at different protocol hierarchies. 1059 o multiple PL PDUs can be aggregated under one TML message 1060 o multiple LFB classes and instances (as indicated in the LFB 1061 selector) can be addressed within one PL PDU 1063 o Multiple operations can be addressed to a single LFB class and 1064 instance 1066 4.3.2.2. Command Pipelining 1068 The protocol allows any number of messages to be issued by the CE 1069 before the corresponding acknowledgments (if requested) have been 1070 returned by the FE. Hence pipelining is inherently supported by the 1071 protocol. Matching responses with requests messages can be done 1072 using the correlator field in the message header. 1074 4.3.3. Heartbeat Mechanism 1076 Heartbeats (HB) between FEs and CEs are traffic sensitive. An HB is 1077 sent only if no PL traffic is sent between the CE and FE within a 1078 configured interval. This has the effect of reducing the amount of 1079 HB traffic in the case of busy PL periods. 1081 An HB can be sourced by either the CE or FE. When sourced by the CE, 1082 a response can be requested (similar to the ICMP ping protocol). The 1083 FE can only generate HBs in the case of being configured to do so by 1084 the CE. Refer to Section 7.3.1 and Section 7.10 for details. 1086 4.3.4. FE Object and FE Protocol LFBs 1088 All PL messages operate on LFB constructs, as this provides more 1089 flexibility for future enhancements. This means that maintenance and 1090 configurability of FEs, NE, as well as the ForCES protocol itself 1091 must be expressed in terms of this LFB architecture. For this reason 1092 special LFBs are created to accommodate this need. 1094 In addition, this shows how the ForCES protocol itself can be 1095 controlled by the very same type of structures (LFBs) it uses to 1096 control functions such as IP forwarding, filtering, etc. 1098 To achieve this, the following specialized LFBs are introduced: 1100 o FE Protocol LFB which is used to control the ForCES protocol. 1102 o FE Object LFB which is used to control attributes relative to the 1103 FE itself. Such attributes include FEState [FE-MODEL], vendor, 1104 etc. 1106 These LFBs are detailed in Section 7.3. 1108 4.4. Protocol Scenarios 1110 This section provides a very high level description of sample message 1111 sequences between a CE and FE. For protocol message encoding refer 1112 to Section 6.1 and for the semantics of the protocol refer to 1113 Section 4.3. 1115 4.4.1. Association Setup State 1117 The associations among CEs and FEs are initiated via Association 1118 setup message from the FE. If a setup request is granted by the CE, 1119 a successful setup response message is sent to the FE. If CEs and 1120 FEs are operating in an insecure environment then the security 1121 associations have to be established between them before any 1122 association messages can be exchanged. The TML will take care of 1123 establishing any security associations. 1125 This is typically followed by capability query, topology query, etc. 1126 When the FE is ready to start forwarding data traffic, it sends an FE 1127 UP Event message to the CE. When the CE is ready, it responds by 1128 enabling the FE by setting the FEStatus to Adminup (Refer to 1129 [FE-MODEL] for details). This indicates to the FE to start 1130 forwarding data traffic. At this point the association establishment 1131 is complete. These sequences of messages are illustrated in the 1132 Figure 8 below. 1134 FE PL CE PL 1136 | | 1137 | Asso Setup Req | 1138 |---------------------->| 1139 | | 1140 | Asso Setup Resp | 1141 |<----------------------| 1142 | | 1143 | LFBx Query capability | 1144 |<----------------------| 1145 | | 1146 | LFBx Query Resp | 1147 |---------------------->| 1148 | | 1149 | FEO Query (Topology) | 1150 |<----------------------| 1151 | | 1152 | FEO Query Resp | 1153 |---------------------->| 1154 | | 1155 | FEO UP Event | 1156 |---------------------->| 1157 | | 1158 | Config FEO Adminup | 1159 |<----------------------| 1160 | | 1161 | FEO Config-Resp | 1162 |---------------------->| 1163 | | 1165 Figure 8: Message exchange between CE and FE to establish an NE 1166 association 1168 On successful completion of this state, the FE joins the NE. 1170 4.4.2. Association Established state or Steady State 1172 In this state, the FE is continuously updated or queried. The FE may 1173 also send asynchronous event notifications to the CE, synchronous 1174 heartbeat messages, or packet redirect message to the CE. This 1175 continues until a termination (or deactivation) is initiated by 1176 either the CE or FE. Figure 9 below, helps illustrate this state. 1178 FE PL CE PL 1180 | | 1181 | Heart Beat | 1182 |<---------------------------->| 1183 | | 1184 | Heart Beat | 1185 |----------------------------->| 1186 | | 1187 | Config-set LFBy (Event sub.) | 1188 |<-----------------------------| 1189 | | 1190 | Config Resp LFBy | 1191 |----------------------------->| 1192 | | 1193 | Config-set LFBx Attr | 1194 |<-----------------------------| 1195 | | 1196 | Config Resp LFBx | 1197 |----------------------------->| 1198 | | 1199 |Config-Query LFBz (Stats) | 1200 |<--------------------------- -| 1201 | | 1202 | Query Resp LFBz | 1203 |----------------------------->| 1204 | | 1205 | FE Event Report | 1206 |----------------------------->| 1207 | | 1208 | Config-Del LFBx Attr | 1209 |<-----------------------------| 1210 | | 1211 | Config Resp LFBx | 1212 |----------------------------->| 1213 | | 1214 | Packet Redirect LFBx | 1215 |----------------------------->| 1216 | | 1217 | Heart Beat | 1218 |<-----------------------------| 1219 . . 1220 . . 1221 | | 1223 Figure 9: Message exchange between CE and FE during steady-state 1224 communication 1226 Note that the sequence of messages shown in the figure serve only as 1227 examples and the message exchange sequences could be different from 1228 what is shown in the figure. Also, note that the protocol scenarios 1229 described in this section do not include all the different message 1230 exchanges that would take place during failover. That is described 1231 in the HA section (Section 8) . 1233 5. TML Requirements 1235 The requirements below are expected to be delivered by the TML. This 1236 text does not define how such mechanisms are delivered. As an 1237 example they could be defined to be delivered via hardware or between 1238 2 or more TML processes on different CEs or FEs in protocol level 1239 schemes. 1241 Each TML must describe how it contributes to achieving the listed 1242 ForCES requirements. If for any reason a TML does not provide a 1243 service listed below a justification needs to be provided. 1245 1. Reliability 1246 As defined by RFC 3654, section 6 #6. 1248 2. Security 1249 TML provides security services to the ForCES PL. A TML layer 1250 should support the following security services and describe how 1251 they are achieved. 1253 * Endpoint authentication of FE and CE 1255 * Message authentication 1257 * Confidentiality service 1259 3. Congestion control 1260 The congestion control scheme used needs to be defined. The 1261 congestion control mechanism defined by the TML should prevent 1262 the FE from being overloaded by the CE or the CE from being 1263 overwhelmed by traffic from the FE. Additionally, the 1264 circumstances under which notification is sent to the PL to 1265 notify it of congestion must be defined. 1267 4. Uni/multi/broadcast addressing/delivery, if any 1268 If there is any mapping between PL and TML level uni/multi/ 1269 broadcast addressing it needs to be defined. 1271 5. HA decisions 1272 It is expected that availability of transport links is the TML's 1273 responsibility. However, based upon its configuration, the PL 1274 may wish to participate in link failover schemes and therefore 1275 the TML must support this capability. 1276 Please refer to Section 8 for details. 1278 6. Encapsulations used 1279 Different types of TMLs will encapsulate the PL messages on 1280 different types of headers. The TML needs to specify the 1281 encapsulation used. 1283 7. Prioritization 1284 It is expected that the TML will be able to handle up to 8 1285 priority levels needed by the PL and will provide preferential 1286 treatment. 1287 While the TML needs to define how this is achieved, it should be 1288 noted that the requirement for supporting up to 8 priority levels 1289 does not mean that the underlying TML MUST be capable of 1290 providing up to 8 actual priority levels. In the event that the 1291 underlying TML layer does not have support for 8 priority levels, 1292 the supported priority levels should be divided between the 1293 available TML priority levels. For example, if the TML only 1294 supports 2 priority levels, the 0-3 could go in one TML priority 1295 level, while 4-7 could go in the other. 1296 The TML MUST NOT reorder config packets with the same priority. 1298 8. Protection against DoS attacks 1299 As described in RFC 3654, section 6 1301 5.1. TML Parameterization 1303 It is expected that it should be possible to use a configuration 1304 reference point, such as the FEM or the CEM, to configure the TML. 1306 Some of the configured parameters may include: 1308 o PL ID 1310 o Connection Type and associated data. For example if a TML uses 1311 IP/TCP/UDP, then parameters such as TCP and UDP port and IP 1312 addresses need to be configured. 1314 o Number of transport connections 1316 o Connection capability, such as bandwidth, etc. 1318 o Allowed/supported connection QoS policy (or congestion control 1319 policy) 1321 6. Message Encapsulation 1323 All PL PDUs start with a common header [Section 6.1] followed by a 1324 one or more TLVs [Section 6.2] which may nest other TLVs 1325 [Section 6.2.1]. All fields are in network byte order. 1327 6.1. Common Header 1329 0 1 2 3 1330 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 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1332 |version| rsvd | Message Type | Length | 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1334 | Source ID | 1335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1336 | Destination ID | 1337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1338 | Correlator[32:63] | 1339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 | Correlator[0:31] | 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 | Flags | 1343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1345 Figure 10: Common Header 1347 The message is 32 bit aligned. 1349 Version (4 bit): 1350 Version number. Current version is 1. 1352 rsvd (4 bit): 1353 Unused at this point. A receiver should not interpret this 1354 field. Senders MUST set it to zero and receivers MUST ignore 1355 this field. 1357 Message Type (8 bits): 1358 Commands are defined in Section 7. 1360 Length (16 bits): 1361 length of header + the rest of the message in DWORDS (4 byte 1362 increments). 1364 Source ID (32 bit): 1366 Dest ID (32 bit): 1368 * Each of the source and destination IDs are 32 bit IDs which 1369 are unique NE-wide and which identify the termination points 1370 of a ForCES PL message. 1372 * IDs allow multi/broad/unicast addressing with the following 1373 approach: 1375 a. A split address space is used to distinguish FEs from 1376 CEs. Even though in a large NE there are typically two 1377 or more orders of magnitude more FEs than CEs, the 1378 address space is split uniformly for simplicity. 1380 b. The address space allows up to 2^30 (over a billion) CEs 1381 and the same amount of FEs. 1383 0 1 2 3 1384 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 1385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 |TS | sub-ID | 1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1389 Figure 11: ForCES ID Format 1391 c. The 2 most significant bits called Type Switch (TS) are 1392 used to split the ID space as follows: 1394 TS Corresponding ID range Assignment 1395 -- ---------------------- ---------- 1396 0b00 0x00000000 to 0x3FFFFFFF FE IDs (2^30) 1397 0b01 0x40000000 to 0x7FFFFFFF CE IDs (2^30) 1398 0b10 0x80000000 to 0xBFFFFFFF reserved 1399 0b11 0xC0000000 to 0xFFFFFFEF multicast IDs (2^30 - 16) 1400 0b11 0xFFFFFFF0 to 0xFFFFFFFC reserved 1401 0b11 0xFFFFFFFD all CEs broadcast 1402 0b11 0xFFFFFFFE all FEs broadcast 1403 0b11 0xFFFFFFFF all FEs and CEs (NE) broadcast 1405 Figure 12: Type Switch ID Space 1407 * Multicast or broadcast IDs are used to group endpoints (such 1408 as CEs and FES). As an example one could group FEs in some 1409 functional group, by assigning a multicast ID. Likewise, 1410 subgroups of CEs that act, for instance, in a back-up mode 1411 may be assigned a multicast ID to hide them from the FE. 1413 + Multicast IDs can be used for both source or destination 1414 IDs. 1416 + Broadcast IDs can be used only for destination IDs. 1418 * This document does not discuss how a particular multicast ID 1419 is associated to a given group though it could be done via 1420 configuration process. The list of IDs an FE owns or is part 1421 of are listed on the FE Object LFB. 1423 Correlator (64 bits) 1424 This field is set by the CE to correlate ForCES Request Messages 1425 with the corresponding Response messages from the FE. 1426 Essentially it is a cookie. The correlator is handled 1427 transparently by the FE, i.e., for a particular Request message 1428 the FE MUST assign the same correlator value in the corresponding 1429 Response message. In the case where the message from the CE does 1430 not elicit a response, this field may not be useful. 1432 The correlator field could be used in many implementations 1433 specific ways by the CE. For example, the CE could split the 1434 correlator into a 32-bit transactional identifier and 32-bit 1435 message sequence identifier. Another example is a 64-bit pointer 1436 to a context block. All such implementation specific use of the 1437 correlator is outside the scope of this specification. 1439 Whenever the correlator field is not relevant, because no message 1440 is expected, the correlator field is set to 0. 1442 Flags(32 bits): 1443 Identified so far: 1445 0 1 2 3 1446 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 1447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1448 | | | | | | | | 1449 |ACK| Pri |Rsr |EM |A|TP | Reserved | 1450 | | | vd. | |T| | | 1451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1453 Figure 13: Header Flags 1455 - ACK: ACK indicator (2 bit) 1456 The ACK indicator flag is only used by the CE when sending a 1457 Config Message (Section 7.6.1) or a HB message (Section 7.10) 1458 to indicate to the message receiver whether or not a response 1459 is required by the sender. Note that for all other messages 1460 than the Config Message or the HB Message this flag MUST be 1461 ignored. 1463 The flag values are defined as below: 1465 'NoACK' (0b00) - to indicate that the message receiver 1466 MUST not send any response message back to this message 1467 sender. 1469 'SuccessACK'(0b01) - to indicate the message receiver 1470 MUST send a response message back only when the message 1471 has been successfully processed by the receiver. 1473 'FailureACK'(0b10) - to indicate the message receiver 1474 MUST send a response message back only when there is 1475 failure by the receiver in processing (executing) the 1476 message. In other words, if the message can be processed 1477 successfully, the sender will not expect any response 1478 from the receiver. 1480 'AlwaysACK' (0b11) - to indicate the message receiver 1481 MUST send a response message. 1483 Note that in above definitions, the term success implies a 1484 complete execution without any failure of the message. 1485 Anything else than a complete successful execution is defined 1486 as a failure for the message processing. As a result, for 1487 the execution modes (defined in Section 4.3.1.1) like 1488 execute-all-or-none, execute-until-failure, and continue- 1489 execute-on-failure, if any single operation among several 1490 operations in the same message fails, it will be treated as a 1491 failure and result in a response if the ACK indicator has 1492 been set to 'FailureACK' or 'AlwaysACK'. 1494 Also note that, other than in Config and HB Messages, 1495 requirements for responses of messages are all given in a 1496 default way rather than by ACK flags. The default 1497 requirements of these messages and the expected responses are 1498 summarized below. Detailed descriptions can be found in the 1499 individual message definitions: 1501 + Association Setup Message always expects a response. 1503 + Association Teardown Message, and Packet Redirect 1504 Message, never expect responses. 1506 + Query Message always expects a response. 1508 + Response message never expects further responses. 1510 - Pri: Priority (3 bits) 1511 ForCES protocol defines 8 different levels of priority (0-7). 1512 The priority level can be used to distinguish between 1513 different protocol message types as well as between the same 1514 message type. The higher the priority value, the more 1515 important the PDU is. For example, the REDIRECT packet 1516 message could have different priorities to distinguish 1517 between routing protocols packets and ARP packets being 1518 redirected from FE to CE. The Normal priority level is 1. 1519 The different priorities imply messages could be re-ordered; 1520 however, re-ordering is undesirable when it comes to a set of 1521 messages within a transaction and caution should be exercised 1522 to avoid this from happening. 1524 - EM: Execution Mode (2 bits) 1525 There are 3 execution modes refer to Section 4.3.1.1 for 1526 details. 1528 Reserved..................... (0b00) 1530 `execute-all-or-none` ....... (0b01) 1532 `execute-until-failure` ..... (0b10) 1534 `continue-execute-on-failure` (0b11) 1536 - AT: Atomic Transaction (1 bit) 1537 This flag indicates if the message is stand-alone message or 1538 one of multiple messages that belongs to 2PC transaction 1539 operations. See Section 4.3.1.2.2 for details. 1541 Stand-alone message ......... (0b0) 1543 2PC transaction message ..... (0b1) 1545 - TP: Transaction Phase (2 bits) 1546 A message from the CE to the FE within a transaction could be 1547 indicative of the different phases the transaction is in. 1548 Refer to Section 4.3.1.2.2 for details. 1550 SOT (start of transaction) ..... (0b00) 1552 MOT (Middle of transaction) .... (0b01) 1554 EOT (end of transaction) ........(0b10) 1556 ABT (abort) .....................(0b11) 1558 6.2. Type Length Value (TLV) Structuring 1560 TLVs are extensively used by the ForCES protocol. TLVs have some 1561 very nice properties which make them a good candidate for encoding 1562 the XML definitions of the LFB class model. These are: 1564 o Providing for binary type-value encoding that is close to the XML 1565 string tag-value scheme. 1567 o Allowing for fast generalized binary-parsing functions. 1569 o Allowing for forward and backward tag compatibility. This is 1570 equivalent to the XML approach i.e old applications can ignore new 1571 TLVs and newer applications can ignore older TLVs. 1573 0 1 2 3 1574 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 1575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 | TLV Type | TLV Length | 1577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1578 | Value (Essentially the TLV Data) | 1579 ~ ~ 1580 ~ ~ 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1583 Figure 14: TLV Representation 1585 TLV Type (16): 1586 The TLV type field is two octets, and semantically 1587 indicates the type of data encapsulated within the 1588 TLV. 1590 TLV Length (16): 1591 The TLV length field is two octets, and includes the 1592 length of the TLV type (2 octets), TLV Length (2 1593 octets), and the length of the TLV data found in the 1594 value field, in octets. Note that this length is 1595 the actual length of the value, before any padding 1596 for alignment is added. 1598 TLV Value (variable): 1599 The TLV value field carries the data. For 1600 extensibility, the TLV value may in fact be a TLV. 1601 Padding is required when the length is not a 1602 multiple of 32 bits, and is the minimum number of 1603 bytes required to bring the TLV to a multiple of 32 1604 bits. The length of the value before padding is 1605 indicated by the TLV Length field. Note: The value 1606 field could be empty which implies the minimal 1607 length a TLV could be is 4 (length of "T" field and 1608 length of "L" field). 1610 6.2.1. Nested TLVs 1612 TLV values can be other TLVs. This provides the benefits of protocol 1613 flexibility (being able to add new extensions by introducing new TLVs 1614 when needed). The nesting feature also allows for a conceptual 1615 optimization with the XML LFB definitions to binary PL representation 1616 (represented by nested TLVs). 1618 6.2.2. Scope of the T in TLV 1620 The "Type" values in the TLV are global in scope. This means that 1621 wherever TLVs occur in the PDU, a specific Type value refers to the 1622 same Type of TLV. This is a design choice that was made to ease 1623 debugging of the protocol. 1625 6.3. ILV 1627 A slight variation of the TLV known as the ILV. This sets the type 1628 ("T") to be a 32-bit local index that refers to a ForCES component 1629 ID. (refer to Section 6.4.1). The Length part of the ILV is fixed at 1630 32 bits. 1632 0 1 2 3 1633 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 1634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1635 | Identifier | 1636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1637 | Length | 1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1639 | Value | 1640 . . 1641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1643 Figure 15: ILV Representation 1645 It should be noted that the "I" values are of local scope and are 1646 defined by the data declarations from the LFB definition. Refer to 1647 Section 7.1.8 for discussions on usage of ILVs. 1649 6.4. Important Protocol encapsulations 1651 In this section, we review a few encapsulation concepts that are used 1652 by the ForCES protocol for its operations. 1654 We briefly re-introduce two concepts, Paths and Keys, from the model 1655 draft [FE-MODEL] in order to provide context. The reader is referred 1656 to [FE-MODEL] for a lot of the finer details. 1658 For readability reasons, we introduce the encapsulation schemes that 1659 are used to carry content in a protocol message, namely FULLDATA, 1660 SPARSEDATA, and RESULT TLVs. 1662 6.4.1. Paths 1664 The model draft [FE-MODEL] defines an XML-based language that allows 1665 for a formal definition of LFBs. This is similar to the relationship 1666 between ASN.1 and SNMP MIB definition (MIB being analogous to the LFB 1667 and ASN.1 being analogous to the XML model language). Any entity 1668 that the CE configures on an FE MUST be formally defined in an LFB. 1669 These entities could be scalars (e.g., a 32-bit IPv4 address) or 1670 vectors (such as a nexthop table). Each entity within the LFB is 1671 given a numeric 32-bit identifier known as an "component id". This 1672 scheme allows the attribute to be "addressed" in a protocol 1673 construct. 1675 These addressable entities could be hierarchical (e.g., a table 1676 column or a cell within a table row). In order to address 1677 hierarchical data, the concept of a path is introduced by the model 1678 [FE-MODEL]. A path is a series of 32-bit component IDs which are 1679 typically presented in a dot-notation (e.g., 1.2.3.4). Section 1680 (Section 7) formally defines how paths are used to reference data 1681 that is being encapsulated within a protocol message. 1683 6.4.2. Keys 1685 The model draft [FE-MODEL] defines two ways to address table rows. 1686 The standard/common mechanism is to allow table rows to be referenced 1687 by a 32-bit index. The secondary mechanism is via Keys which allow 1688 for content addressing. An example key is a multi-field content key 1689 that uses the IP address and prefix length to uniquely reference an 1690 IPv4 routing table row. In essence, while the common scheme to 1691 address a table row is via its table index, a table row's path could 1692 be derived from a key. The KEYINFO TLV (Section 7) is used to carry 1693 the data that is used to do the lookup. 1695 6.4.3. DATA TLVs 1697 Data from or to the FE is carried in two types of TLVs: FULLDATA TLV 1698 and SPARSEDATA TLV. Responses on operations executed by the FE are 1699 carried in RESULT TLVs. 1701 In FULLDATA TLV, the data is encoded in such a way that a receiver of 1702 such data, by virtue of being armed with knowledge of the path and 1703 the LFB definition, can infer or correlate the TLV "Value" contents. 1704 This is essentially an optimization that helps reduce the amount of 1705 description required for the transported data in the protocol 1706 grammar. Refer to Appendix C for an example of FULLDATA TLVs. 1708 A number of operations in ForCES will need to reference optional data 1709 within larger structures. The SPARSEDATA TLV encoding is provided to 1710 make it easier to encapsulate optionally appearing data components. 1711 Refer to Appendix C for an example of SPARSEDATA TLV. 1713 RESULT TLVs carry responses back from the FE based on a config issued 1714 by the CE. Refer to Appendix C for examples of RESULT TLVs and 1715 Section 7.1.7 for layout. 1717 6.4.4. Addressing LFB entities 1719 Section 6.4.1 and Section 6.4.2 discuss how to target an entity 1720 within an LFB. However, the addressing mechanism used requires that 1721 an LFB type and instance is selected first. The LFB Selector is used 1722 to select an LFB type and instance being targeted. Section 1723 (Section 7) goes into more details; for our purpose, we illustrate 1724 this concept using Figure 16 below. More examples of layouts can be 1725 found reading further into the text (Example: Figure 21). 1727 main hdr (Message type: example "config") 1728 | 1729 | 1730 | 1731 +- T = LFBselect 1732 | 1733 +-- LFBCLASSID (unique per LFB defined) 1734 | 1735 | 1736 +-- LFBInstance (runtime configuration) 1737 | 1738 +-- T = An operation TLV describes what we do to an entity 1739 | //Refer to the OPER-TLV values enumerated below 1740 | //the TLVs that can be used for operations 1741 | 1742 | 1743 +--+-- one or more path encodings to target an entity 1744 | // Refer to the discussion on keys and paths 1745 | 1746 | 1747 +-- The associated data, if any, for the entity 1748 // Refer to discussion on FULL/SPARSE DATA TLVs 1750 Figure 16: Entity Addressing 1752 7. Protocol Construction 1754 A protocol layer PDU consists of a Common Header (defined in Section 1755 Section 6.1 ) and a message body. The Common Header is followed by a 1756 message-type-specific message body. Each message body is formed from 1757 one or more top-level TLVs. A top-level TLV may contain one or more 1758 sub-TLVs; these sub-TLVs are described in this document as OPER-TLVs, 1759 because they describe an operation to be done. 1761 +--------------+--------------+---------------------+---------------+ 1762 | Message Name | Top-Level | OPER-TLV(s) | Reference | 1763 | | TLV | | | 1764 +--------------+--------------+---------------------+---------------+ 1765 | Association | (LFBselect)* | REPORT | Section 7.5.2 | 1766 | Setup | | | | 1767 | | | | | 1768 | Association | ASRresult | none | Section 7.5.2 | 1769 | Setup | | | | 1770 | Response | | | | 1771 | | | | | 1772 | Association | ASTreason | none | Section 7.5.3 | 1773 | Teardown | | | | 1774 | | | | | 1775 | Config | (LFBselect)+ | (SET | SET-PROP | | Section 7.6.1 | 1776 | | | DEL | COMMIT | | | 1777 | | | TRCOMP)+ | | 1778 | | | | | 1779 | Config | LFBselect | (SET-RESPONSE | | Section 7.6.2 | 1780 | Response | | SET-PROP-RESPONSE | | | 1781 | | | DEL-RESPONSE | | | 1782 | | | COMMIT-RESPONSE)+ | | 1783 | | | | | 1784 | Query | (LFBselect)+ | (GET | GET-PROP)+ | Section 7.7.1 | 1785 | | | | | 1786 | Query | (LFBselect)+ | (GET-RESPONSE | | Section 7.7.2 | 1787 | Response | | GET-PROP-RESPONSE)+ | | 1788 | | | | | 1789 | Event | LFBselect | REPORT | Section 7.8 | 1790 | Notification | | | | 1791 | | | | | 1792 | Packet | REDIRECT-TLV | none | Section 7.9 | 1793 | Redirect | | | | 1794 | | | | | 1795 | Heartbeat | none | none | Section 7.10 | 1796 +--------------+--------------+---------------------+---------------+ 1798 Table 1 1800 The different messages are illustrated in Table 1. The different 1801 message type numerical values are defined in Appendix A.1. All the 1802 TLVs values are defined in Appendix A.2. 1804 An LFBselect TLV (refer to Section 7.1.5) contains the LFB Classid 1805 and LFB Instance being referenced as well as the OPER-TLV(s) being 1806 applied to that reference. 1808 Each type of OPER-TLV is constrained as to how it describes the paths 1809 and selectors of interest. The following BNF describes the basic 1810 structure of an OPER-TLV and Table 2 gives the details for each type 1812 OPER-TLV := 1*PATH-DATA-TLV 1813 PATH-DATA-TLV := PATH [DATA] 1814 PATH := flags IDcount IDs [SELECTOR] 1815 SELECTOR := KEYINFO-TLV 1816 DATA := FULLDATA-TLV / SPARSEDATA-TLV / RESULT-TLV / 1817 1*PATH-DATA-TLV 1818 KEYINFO-TLV := KeyID FULLDATA-TLV 1819 FULLDATA-TLV := encoded data component which may nest 1820 further FULLDATA-TLVs 1821 SPARSEDATA-TLV := encoded data that may have optionally 1822 appearing components 1823 RESULT-TLV := Holds result code and optional FULLDATA-TLV 1825 Figure 17: BNF of OPER-TLV 1827 o PATH-DATA-TLV identifies the exact component targeted and may have 1828 zero or more paths associated with it. The last PATH-DATA-TLV in 1829 the case of nesting of paths via the DATA construct in the case of 1830 SET, SET-PROP requests and GET-RESPONSE/GET-PROP-RESPONSE is 1831 terminated by encoded data or response in the form of either 1832 FULLDATA-TLV or SPARSEDATA-TLV or RESULT TLV. 1834 o PATH provides the path to the data being referenced. 1836 * flags (16 bits) are used to further refine the operation to be 1837 applied on the Path. More on these later. 1839 * IDcount(16 bit): count of 32 bit IDs 1841 * IDs: zero or more 32bit IDs (whose count is given by IDcount) 1842 defining the main path. Depending on the flags, IDs could be 1843 field IDs only or a mix of field and dynamic IDs. Zero is used 1844 for the special case of using the entirety of the containing 1845 context as the result of the path. 1847 o SELECTOR is an optional construct that further defines the PATH. 1848 Currently, the only defined selector is the KEYINFO-TLV, used for 1849 selecting an array entry by the value of a key field. The 1850 presence of a SELECTOR is correct only when the flags also 1851 indicate its presence. A mismatch is a protocol format error. 1853 o A KEYINFO TLV contains information used in content keying. 1855 * A KeyID is used in a KEYINFO TLV. It indicates which key for 1856 the current array is being used as the content key for array 1857 entry selection. 1859 * The key's data is the data to look for in the array, in the 1860 fields identified by the key field. The information is encoded 1861 according to the rules for the contents of a FULLDATA-TLV, and 1862 represent the field or fields which make up the key identified 1863 by the KeyID. 1865 o DATA may contain a FULLDATA-TLV, SPARSEDATA-TLV, a RESULT TLV or 1 1866 or more further PATH-DATA selection. FULLDATA and SPARSEDATA are 1867 only allowed on SET or SET-PROP requests, or on responses which 1868 return content information (GET-RESPONSE for example). PATH-DATA 1869 may be included to extend the path on any request. 1871 * Note: Nested PATH-DATA TLVs are supported as an efficiency 1872 measure to permit common subexpression extraction. 1874 * FULLDATA and SPARSEDATA contain "the data" whose path has been 1875 selected by the PATH. Refer to Section 7.1 for details. 1877 * The following table summarizes the applicability and 1878 restrictions of the FULL/SPARSEDATA TLV and the RESULT TLV to 1879 the OPER-TLVs. 1881 +-------------------+-------------------------------+---------------+ 1882 | OPER-TLV | DATA TLV | RESULT TLV | 1883 +-------------------+-------------------------------+---------------+ 1884 | SET | (FULLDATA-TLV | | none | 1885 | | SPARSEDATA-TLV)+ | | 1886 | | | | 1887 | SET-PROP | (FULLDATA-TLV | | none | 1888 | | SPARSEDATA-TLV)+ | | 1889 | | | | 1890 | SET-RESPONSE | none | (RESULT-TLV)+ | 1891 | | | | 1892 | SET-PROP-RESPONSE | none | (RESULT-TLV)+ | 1893 | | | | 1894 | DEL | (FULLDATA-TLV | | none | 1895 | | SPARSEDATA-TLV)+ | | 1896 | | | | 1897 | DEL-RESPONSE | none | (RESULT-TLV)+ | 1898 | | | | 1899 | GET | none | none | 1900 | | | | 1901 | GET-PROP | none | none | 1902 | | | | 1903 | GET-RESPONSE | (FULLDATA-TLV)+ | (RESULT-TLV)* | 1904 | | | | 1905 | GET-PROP-RESPONSE | (FULLDATA-TLV)+ | (RESULT-TLV)* | 1906 | | | | 1907 | REPORT | (FULLDATA-TLV)+ | none | 1908 | | | | 1909 | COMMIT | none | none | 1910 | | | | 1911 | COMMIT-RESPONSE | none | (RESULT-TLV)+ | 1912 | | | | 1913 | TRCOMP | none | none | 1914 +-------------------+-------------------------------+---------------+ 1916 Table 2 1918 o RESULT contains the indication of whether the individual SET or 1919 SET-PROP succeeded. RESULT TLV is included on the assumption that 1920 individual parts of a SET request can succeed or fail separately. 1922 In summary this approach has the following characteristic: 1924 o There can be one or more LFB class ID and instance ID combination 1925 targeted in a message (batch) 1927 o There can one or more operations on an addressed LFB class ID/ 1928 instance ID combination (batch) 1930 o There can be one or more path targets per operation (batch) 1932 o Paths may have zero or more data values associated (flexibility 1933 and operation specific) 1935 It should be noted that the above is optimized for the case of a 1936 single LFB class ID and instance ID targeting. To target multiple 1937 instances within the same class, multiple LFBselects are needed. 1939 7.1. Discussion on encoding 1941 Section 6.4.3 discusses the two types of DATA encodings (FULLDATA and 1942 SPARSEDATA TLV) and the justifications for their existence. In this 1943 section we explain how they are encoded. 1945 7.1.1. Data Packing Rules 1947 The scheme for encoding data used in this doc adheres to the 1948 following rules: 1950 o The Value ("V" of TLV) of FULLDATA TLV will contain the data being 1951 transported. This data will be as was described in the LFB 1952 definition. 1954 o Variable sized data within a FULLDATA TLV will be encapsulated 1955 inside another FULLDATA TLV inside the V of the outer TLV. For 1956 example of such a setup refer to Appendix C and Appendix D 1958 o In the case of FULLDATA TLVs: 1960 * When a table is referred to in the PATH (IDs) of a PATH-DATA- 1961 TLV, then the FULLDATA's "V" will contain that table's row 1962 content prefixed by its 32 bit index/subscript. On the other 1963 hand, when PATH flags are 00, the PATH may contain an index 1964 pointing to a row in table; in such a case, the FULLDATA's "V" 1965 will only contain the content with the index in order to avoid 1966 ambiguity. 1968 7.1.2. Path Flags 1970 The following flags are currently defined: 1972 o SELECTOR Bit: F_SELKEY indicates that a KEY Selector is present 1973 following this path information, and should be considered in 1974 evaluating the path. 1976 7.1.3. Relation of operational flags with global message flags 1978 Global flags, such as the execution mode and the atomicity indicators 1979 defined in the header, apply to all operations in a message. Global 1980 flags provide semantics that are orthogonal to those provided by the 1981 operational flags, such as the flags defined in Path Data. The scope 1982 of operational flags is restricted to the operation. 1984 7.1.4. Content Path Selection 1986 The KEYINFO TLV describes the KEY as well as associated KEY data. 1987 KEYs, used for content searches, are restricted and described in the 1988 LFB definition. 1990 7.1.5. LFBselect-TLV 1992 The LFBselect TLV is an instance of a TLV as defined in Section 6.2. 1993 The definition is as below: 1995 0 1 2 3 1996 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 1997 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1998 | Type = LFBselect | Length | 1999 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2000 | LFB Class ID | 2001 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2002 | LFB Instance ID | 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2004 | OPER-TLV | 2005 . . 2006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2007 ~ ... ~ 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2009 | OPER-TLV | 2010 . . 2011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2013 Figure 18: PL PDU layout 2015 Type: 2016 The type of the TLV is "LFBselect" 2018 Length: 2019 Length of the TLV including the T and L fields, in octets. 2021 LFB Class ID: 2022 This field uniquely recognizes the LFB class/type. 2024 LFB Instance ID: 2025 This field uniquely identifies the LFB instance. 2027 OPER-TLV: 2028 It describes an operation nested in the LFBselect TLV. Note that 2029 usually there SHOULD be at least one OPER-TLV present for an LFB 2030 select TLV, but for the Association Setup Message defined in 2031 Section 7.5.1 where the OPER-TLV is optional. 2033 7.1.6. OPER-TLV 2035 The OPER-TLV is a place holder in the grammar for TLVs that define 2036 operations. The different types are defined in Table 3, below. 2038 +-------------------+--------+--------------------------------------+ 2039 | OPER-TLV | TLV | Comments | 2040 | | "Type" | | 2041 +-------------------+--------+--------------------------------------+ 2042 | SET | 0x0001 | From CE to FE. Used to create or | 2043 | | | add or update attributes | 2044 | | | | 2045 | SET-PROP | 0x0002 | From CE to FE. Used to create or | 2046 | | | add or update attribute properties | 2047 | | | | 2048 | SET-RESPONSE | 0x0003 | From FE to CE. Used to carry | 2049 | | | response of a SET | 2050 | | | | 2051 | SET-PROP-RESPONSE | 0x0004 | From FE to CE. Used to carry | 2052 | | | response of a SET-PROP | 2053 | | | | 2054 | DEL | 0x0005 | From CE to FE. Used to delete or | 2055 | | | remove an attribute | 2056 | | | | 2057 | DEL-RESPONSE | 0x0006 | From FE to CE. Used to carry | 2058 | | | response of a DEL | 2059 | | | | 2060 | GET | 0x0007 | From CE to FE. Used to retrieve an | 2061 | | | attribute | 2062 | | | | 2063 | GET-PROP | 0x0008 | From CE to FE. Used to retrieve an | 2064 | | | attribute property | 2065 | | | | 2066 | GET-RESPONSE | 0x0009 | From FE to CE. Used to carry | 2067 | | | response of a GET | 2068 | | | | 2069 | GET-PROP-RESPONSE | 0x000A | From FE to CE. Used to carry | 2070 | | | response of a GET-PROP | 2071 | | | | 2072 | REPORT | 0x000B | From FE to CE. Used to carry an | 2073 | | | asynchronous event | 2074 | | | | 2075 | COMMIT | 0x000C | From CE to FE. Used to issue a | 2076 | | | commit in a 2PC transaction | 2077 | | | | 2078 | COMMIT-RESPONSE | 0x000D | From an FE to CE. Used to confirm a | 2079 | | | commit in a 2PC transaction | 2080 | | | | 2081 | TRCOMP | 0x000E | From CE to FE. Used to indicate | 2082 | | | NE-wide success of 2PC transaction | 2083 +-------------------+--------+--------------------------------------+ 2085 Table 3 2087 Different messages define OPER-TLV are valid and how they are used 2088 (refer to Table 1 and Table 2). 2090 SET, SET-PROP, and GET/GET-PROP requests are issued by the CE and do 2091 not carry RESULT TLVs. On the other hand, SET-RESPONSE, SET-PROP- 2092 RESPONSE and GET-RESPONSE/GET-PROP-RESPONSE carry RESULT TLVs. 2094 A GET-RESPONSE in response to a successful GET will have FULLDATA 2095 TLVs added to the leaf paths to carry the requested data. For GET 2096 operations that fail, instead of the FULLDATA TLV there will be a 2097 RESULT TLV. 2099 For a SET-RESPONSE/SET-PROP-RESPONSE, each FULLDATA or SPARSEDATA TLV 2100 in the original request will be replaced with a RESULT TLV in the 2101 response. If the request set the FailureACK flag, then only those 2102 items which failed will appear in the response. If the request was 2103 for AlwaysACK, then all components of the request will appear in the 2104 response with RESULT TLVs. 2106 Note that if a SET/SET-PROP request with a structure in a FULLDATA is 2107 issued, and some field in the structure is invalid, the FE will not 2108 attempt to indicate which field was invalid, but rather will indicate 2109 that the operation failed. Note further that if there are multiple 2110 errors in a single leaf PATH-DATA/FULLDATA, the FE can select which 2111 error it chooses to return. So if a FULLDATA for a SET/SET-PROP of a 2112 structure attempts to write one field which is read only, and 2113 attempts to set another field to an invalid value, the FE can return 2114 indication of either error. 2116 A SET/SET-PROP operation on a variable length component with a length 2117 of 0 for the item is not the same as deleting it. If the CE wishes 2118 to delete then the DEL operation should be used whether the path 2119 refers to an array component or an optional structure component. 2121 7.1.7. Result TLV 2123 The RESULT TLV is an instance of TLV defined in Section 6.2. The 2124 definition is as below: 2126 0 1 2 3 2127 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 2128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2129 | Type = RESULT | Length | 2130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2131 | Result Value | Reserved | 2132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2134 Figure 19: Result TLV 2135 Defined Result Values 2137 +-----------------------------+-----------+-------------------------+ 2138 | Result Value | Value | Definition | 2139 +-----------------------------+-----------+-------------------------+ 2140 | E_SUCCESS | 0x00 | Success | 2141 | | | | 2142 | E_INVALID_HEADER | 0x01 | Unspecified error with | 2143 | | | header. | 2144 | | | | 2145 | E_LENGTH_MISMATCH | 0x02 | Header length field | 2146 | | | does not match actual | 2147 | | | packet length. | 2148 | | | | 2149 | E_VERSION_MISMATCH | 0x03 | Unresolvable mismatch | 2150 | | | in versions. | 2151 | | | | 2152 | E_INVALID_DESTINATION_PID | 0x04 | Destination PID is | 2153 | | | invalid for the message | 2154 | | | receiver. | 2155 | | | | 2156 | E_LFB_UNKNOWN | 0x05 | LFB Class ID is not | 2157 | | | known by receiver. | 2158 | | | | 2159 | E_LFB_NOT_FOUND | 0x06 | LFB Class ID is known | 2160 | | | by receiver but not | 2161 | | | currently in use. | 2162 | | | | 2163 | E_LFB_INSTANCE_ID_NOT_FOUND | 0x07 | LFB Class ID is known | 2164 | | | but the specified | 2165 | | | instance of that class | 2166 | | | does not exist. | 2167 | | | | 2168 | E_INVALID_PATH | 0x08 | The specified path is | 2169 | | | impossible. | 2170 | | | | 2171 | E_COMPONENT_DOES_NOT_EXIST | 0x09 | The specified path is | 2172 | | | possible but the | 2173 | | | component does not | 2174 | | | exist (e.g., attempt to | 2175 | | | modify a table row that | 2176 | | | has not been created). | 2177 | | | | 2178 | E_EXISTS | 0x0A | The specified object | 2179 | | | exists but it cannot | 2180 | | | exist for the operation | 2181 | | | to succeed (e.g., | 2182 | | | attempt to add an | 2183 | | | existing LFB instance | 2184 | | | or array subscript). | 2185 | | | | 2186 | E_NOT_FOUND | 0x0B | The specified object | 2187 | | | does not exist but it | 2188 | | | must exist for the | 2189 | | | operation to succeed | 2190 | | | (e.g., attempt to | 2191 | | | delete a non-existing | 2192 | | | LFB instance or array | 2193 | | | subscript). | 2194 | | | | 2195 | E_READ_ONLY | 0x0C | Attempt to modify a | 2196 | | | read-only value. | 2197 | | | | 2198 | E_INVALID_ARRAY_CREATION | 0x0D | Attempt to create an | 2199 | | | array with an unallowed | 2200 | | | subscript. | 2201 | | | | 2202 | E_VALUE_OUT_OF_RANGE | 0x0E | Attempt to set a | 2203 | | | parameter to a value | 2204 | | | outside of its | 2205 | | | allowable range. | 2206 | | | | 2207 | E_CONTENTS_TOO_LONG | 0x0D | Attempt to write | 2208 | | | contents larger than | 2209 | | | the target object space | 2210 | | | (i.e., exceeding a | 2211 | | | buffer). | 2212 | | | | 2213 | E_INVALID_PARAMETERS | 0x10 | Any other error with | 2214 | | | data parameters. | 2215 | | | | 2216 | E_INVALID_MESSAGE_TYPE | 0x11 | Message type is not | 2217 | | | acceptable. | 2218 | | | | 2219 | E_INVALID_FLAGS | 0x12 | Message flags are not | 2220 | | | acceptable for the | 2221 | | | given message type. | 2222 | | | | 2223 | E_INVALID_TLV | 0x13 | A TLV is not acceptable | 2224 | | | for the given message | 2225 | | | type. | 2226 | E_EVENT_ERROR | 0x14 | Unspecified error while | 2227 | | | handling an event. | 2228 | | | | 2229 | E_NOT_SUPPORTED | 0x15 | Attempt to perform a | 2230 | | | valid ForCES operation | 2231 | | | that is unsupported by | 2232 | | | the message receiver. | 2233 | | | | 2234 | E_MEMORY_ERROR | 0x16 | A memory error occurred | 2235 | | | while processing a | 2236 | | | message (no error | 2237 | | | detected in the message | 2238 | | | itself) | 2239 | | | | 2240 | E_INTERNAL_ERROR | 0x17 | An unspecified error | 2241 | | | occurred while | 2242 | | | processing a message | 2243 | | | (no error detected in | 2244 | | | the message itself) | 2245 | | | | 2246 | - | 0x18-0xFE | Reserved | 2247 | | | | 2248 | E_UNSPECIFIED_ERROR | 0xFF | Unspecified error (for | 2249 | | | when the FE can not | 2250 | | | decide what went wrong) | 2251 +-----------------------------+-----------+-------------------------+ 2253 Table 4 2255 7.1.8. DATA TLV 2257 A FULLDATA TLV has "T"= FULLDATA and a 16-bit Length followed by the 2258 data value/contents. Likewise, a SPARSEDATA TLV has "T" = 2259 SPARSEDATA, a 16-bit Length, followed by the data value/contents. In 2260 the case of the SPARSEDATA, each component in the Value part of the 2261 TLV will be further encapsulated in an ILV. 2263 Below are the encoding rules for the FULLDATA and SPARSEDATA TLVs. 2264 Appendix C is very useful in illustrating these rules: 2266 1. Both ILVs and TLVs MUST be 32 bit aligned. Any padding bits used 2267 for the alignment MUST be zero on transmission and MUST be 2268 ignored upon reception. 2270 2. FULLDATA TLVs may be used at a particular path only if every 2271 component at that path level is present. In example 1(c) of 2272 Appendix C this concept is illustrated by the presence of all 2273 components of the structure S in the FULLDATA TLV encoding. This 2274 requirement holds regardless of whether the fields are fixed or 2275 variable length, mandatory or optional. 2277 * If a FULLDATA TLV is used, the encoder MUST lay out data for 2278 each component in the same order in which the data was defined 2279 in the LFB specification. This ensures the decoder is able to 2280 retrieve the data. To use the example 1 again in Appendix C, 2281 this implies the encoder/decoder is assumed to have knowledge 2282 of how structure S is laid out in the definition. 2284 * In the case of a SPARSEDATA, it does not need to be ordered 2285 since the "I" in the ILV uniquely identifies the component. 2286 Examples 1(a) and 1(b) illustrate the power of SPARSEDATA 2287 encoding. 2289 3. Inside a FULLDATA TLV 2291 * The values for atomic, fixed-length fields are given without 2292 any TLV or ILV encapsulation. 2294 * The values for atomic, variable-length fields are given inside 2295 FULLDATA TLVs. 2297 4. Inside a SPARSEDATA TLV 2299 * The values for atomic fields may be given with ILVs (32-bit 2300 index, 32-bit length) 2302 5. Any of the FULLDATA TLVs can contain an ILV but an ILV cannot 2303 contain a FULLDATA. This is because it is hard to disambiguate 2304 ILV since an I is 32 bits and a T is 16 bits. 2306 6. A FULLDATA can also contain a FULLDATA for variable sized 2307 components. The decoding disambiguation is assumed from rule #3 2308 above. 2310 7.1.9. SET and GET Relationship 2312 It is expected that a GET-RESPONSE would satisfy the following: 2314 o It would have exactly the same path definitions as those sent in 2315 the GET. The only difference being a GET-RESPONSE will contain 2316 FULLDATA TLVs. 2318 o It should be possible to take the same GET-RESPONSE and convert it 2319 to a SET successfully by merely changing the T in the operational 2320 TLV. 2322 o There are exceptions to this rule: 2324 1. When a KEY selector is used with a path in a GET operation, 2325 that selector is not returned in the GET-RESPONSE; instead the 2326 cooked result is returned. Refer to the examples using KEYS 2327 to see this. 2329 2. When dumping a whole table in a GET, the GET-RESPONSE that 2330 merely edits the T to be SET will end up overwriting the 2331 table. 2333 7.2. Protocol Encoding Visualization 2335 The figure below shows a general layout of the PL PDU. A main header 2336 is followed by one or more LFB selections each of which may contain 2337 one or more operation. 2339 main hdr (Config in this case) 2340 | 2341 | 2342 +--- T = LFBselect 2343 | | 2344 | +-- LFBCLASSID 2345 | | 2346 | | 2347 | +-- LFBInstance 2348 | | 2349 | +-- T = SET 2350 | | | 2351 | | +-- // one or more path targets 2352 | | // with their data here to be added 2353 | | 2354 | +-- T = DEL 2355 | . | 2356 | . +-- // one or more path targets to be deleted 2357 | 2358 | 2359 +--- T = LFBselect 2360 | | 2361 | +-- LFBCLASSID 2362 | | 2363 | | 2364 | +-- LFBInstance 2365 | | 2366 | + -- T= SET 2367 | | . 2368 | | . 2369 | + -- T= DEL 2370 | | . 2371 | | . 2372 | | 2373 | + -- T= SET 2374 | | . 2375 | | . 2376 | 2377 | 2378 +--- T = LFBselect 2379 | 2380 +-- LFBCLASSID 2381 | 2382 +-- LFBInstance 2383 . 2384 . 2385 . 2387 Figure 20: PL PDU logical layout 2389 The figure below shows a more detailed example of the general layout 2390 of the operation within a targeted LFB selection. The idea is to 2391 show the different nesting levels a path could take to get to the 2392 target path. 2394 T = SET 2395 | | 2396 | +- T = Path-data 2397 | | 2398 | + -- flags 2399 | + -- IDCount 2400 | + -- IDs 2401 | | 2402 | +- T = Path-data 2403 | | 2404 | + -- flags 2405 | + -- IDCount 2406 | + -- IDs 2407 | | 2408 | +- T = Path-data 2409 | | 2410 | + -- flags 2411 | + -- IDCount 2412 | + -- IDs 2413 | + -- T = KEYINFO 2414 | | + -- KEY_ID 2415 | | + -- KEY_DATA 2416 | | 2417 | + -- T = FULLDATA 2418 | + -- data 2419 | 2420 | 2421 T = SET 2422 | | 2423 | +- T = Path-data 2424 | | | 2425 | | + -- flags 2426 | | + -- IDCount 2427 | | + -- IDs 2428 | | | 2429 | | + -- T = FULLDATA 2430 | | + -- data 2431 | +- T = Path-data 2432 | | 2433 | + -- flags 2434 | + -- IDCount 2435 | + -- IDs 2436 | | 2437 | + -- T = FULLDATA 2438 | + -- data 2439 T = DEL 2440 | 2441 +- T = Path-data 2442 | 2443 + -- flags 2444 + -- IDCount 2445 + -- IDs 2446 | 2447 +- T = Path-data 2448 | 2449 + -- flags 2450 + -- IDCount 2451 + -- IDs 2452 | 2453 +- T = Path-data 2454 | 2455 + -- flags 2456 + -- IDCount 2457 + -- IDs 2458 + -- T = KEYINFO 2459 | + -- KEY_ID 2460 | + -- KEY_DATA 2461 +- T = Path-data 2462 | 2463 + -- flags 2464 + -- IDCount 2465 + -- IDs 2467 Figure 21: Sample operation layout 2469 Appendix D shows a more concise set of use-cases on how the data 2470 encoding is done. 2472 7.3. Core ForCES LFBs 2474 There are two LFBs that are used to control the operation of the 2475 ForCES protocol and to interact with FEs and CEs: 2477 o FE Protocol LFB 2478 o FE Object LFB 2480 Although these LFBs have the same form and interface as other LFBs, 2481 they are special in many respects. They have fixed well-known LFB 2482 Class and Instance IDs. They are statically defined (no dynamic 2483 instantiation allowed) and their status cannot be changed by the 2484 protocol: any operation to change the state of such LFBs (for 2485 instance, in order to disable the LFB) must result in an error. 2486 Moreover, these LFBs must exist before the first ForCES message can 2487 be sent or received. All attributes in these LFBs must have pre- 2488 defined default values. Finally, these LFBs do not have input or 2489 output ports and do not integrate into the intra-FE LFB topology. 2491 7.3.1. FE Protocol LFB 2493 The FE Protocol LFB is a logical entity in each FE that is used to 2494 control the ForCES protocol. The FE Protocol LFB Class ID is 2495 assigned the value 0x1. The FE Protocol LFB Instance ID is assigned 2496 the value 0x1. There MUST be one and only one instance of the FE 2497 Protocol LFB in an FE. The values of the attributes in the FE 2498 Protocol LFB have pre-defined default values that are specified here. 2499 Unless explicit changes are made to these values using Config 2500 messages from the CE, these default values MUST be used for correct 2501 operation of the protocol. 2503 The formal definition of the FE Protocol Object LFB can be found in 2504 Appendix B. 2506 7.3.1.1. FE Protocol capabilities 2508 FE Protocol capabilities are read-only. 2510 7.3.1.1.1. SupportableVersions 2512 ForCES protocol version(s) supported by the FE 2514 7.3.1.1.2. FE Protocol Attributes 2516 FE Protocol attributes (can be read and set). 2518 7.3.1.1.2.1. CurrentRunningVersion 2520 Current running version of the ForCES protocol 2522 7.3.1.1.2.2. FEID 2524 FE unicast ID 2526 7.3.1.1.2.3. MulticastFEIDs 2528 FE multicast ID(s) list - this is a list of multicast IDs that the FE 2529 belongs to. These IDs are configured by the CE. 2531 7.3.1.1.2.4. CEHBPolicy 2533 CE heartbeat policy - This policy, along with the parameter 'CE 2534 Heartbeat Dead Interval (CE HDI)' as described below defines the 2535 operating parameters for the FE to check the CE liveness. The policy 2536 values with meanings are listed as below: 2538 o 0 (default) - This policy specifies that the CE will send a 2539 Heartbeat Message to the FE(s) whenever the CE reaches a time 2540 interval within which no other PL messages were sent from the CE 2541 to the FE(s); refer to Section 4.3.3 and Section 7.10 for details. 2542 The CE HDI attribute as described below is tied to this policy. 2544 o 1 - The CE will not generate any HB messages. This actually means 2545 CE does not want the FE to check the CE liveness. 2547 o Others - reserved. 2549 7.3.1.1.2.5. CEHDI 2551 CE Heartbeat Dead Interval (CE HDI) - The time interval the FE uses 2552 to check the CE liveness. If FE has not received any messages from 2553 CE within this time interval, FE deduces lost connectivity which 2554 implies that the CE is dead or the association to the CE is lost. 2555 Default value 30 s. 2557 7.3.1.1.2.6. FEHBPolicy 2559 FE heartbeat policy - This policy, along with the parameter 'FE 2560 Heartbeat Interval (FE HI)', defines the operating parameters for how 2561 the FE should behave so that the CE can deduce its liveness. The 2562 policy values and the meanings are: 2564 o 0 (default) - The FE should not generate any Heartbeat messages. 2565 In this scenario, the CE is responsible for checking FE liveness 2566 by setting the PL header ACK flag of the message it sends to 2567 AlwaysACK. The FE responds to CE whenever CE sends such Heartbeat 2568 Request Message. Refer to Section 7.10 and Section 4.3.3 for 2569 details. 2571 o 1 - This policy specifies that FE must actively send a Heartbeat 2572 Message if it reaches the time interval assigned by the FE HI as 2573 long as no other messages were sent from FE to CE during that 2574 interval as described in Section 4.3.3. 2576 o Others - Reserved. 2578 7.3.1.1.2.7. FEHI 2580 FE Heartbeat Interval (FE HI) - The time interval the FE should use 2581 to send HB as long as no other messages were sent from FE to CE 2582 during that interval as described in Section 4.3.3. The default 2583 value for an FE HI is 500ms. 2585 7.3.1.1.2.8. CEID 2587 Primary CEID - The CEID that the FE is associated with. 2589 7.3.1.1.2.9. LastCEID 2591 Last Primary CEID - The CEID of the last CE that that the FE 2592 associated with. This CE ID is reported to the new Primary CEID. 2594 7.3.1.1.2.10. BackupCEs 2596 The list of backup CEs an FE can use as backups. Refer to Section 8 2597 for details. 2599 7.3.1.1.2.11. CEFailoverPolicy 2601 CE failover policy - This specifies the behavior of the FE when the 2602 association with the CE is lost. There is a very tight relation 2603 between CE failover policy and Section 7.3.1.1.2.8, 2604 Section 7.3.1.1.2.10, Section 7.3.1.1.2.12, and Section 8. When an 2605 association is lost, depending on configuration, one of the policies 2606 listed below is activated. 2608 o 0 (default) - FE should stop functioning immediately and 2609 transition to FE DOWN. 2611 o 1 - The FE should continue running and do what it can even without 2612 an associated CE. This basically requires that the FE support CE 2613 Graceful restart (and defines such support in its capabilities). 2614 If the CEFTI expires before the FE re-associates with either the 2615 primary (Section 7.3.1.1.2.8) or one of possibly several backup 2616 CEs (Section 7.3.1.1.2.10), the FE will go operationally down. 2618 o Others - Reserved 2620 7.3.1.1.2.12. CEFTI 2622 CE Failover Timeout Interval (CEFTI) - The time interval associated 2623 with the CE failover policy case '0' and '2'. The default value is 2624 set to 300 seconds. Note that it is advisable to set the CEFTI value 2625 much higher than the CE Heartbeat Dead Interval (CE HDI) since the 2626 effect of expiring this parameter is devastating to the operation of 2627 the FE. 2629 7.3.1.1.2.13. FERestartPolicy 2631 FE restart policy - This specifies the behavior of the FE during an 2632 FE restart. The restart may be from an FE failure or other reasons 2633 that have made FE down and then need to restart. The values are 2634 defined as below: 2636 o 0(default)- Restart the FE from scratch. In this case, the FE 2637 should start from the pre-association phase. 2639 o others - Reserved for future use. 2641 7.3.2. FE Object LFB 2643 The FE Object LFB is a logical entity in each FE and contains 2644 attributes relative to the FE itself, and not to the operation of the 2645 ForCES protocol. 2647 The formal definition of the FE Object LFB can be found in 2648 [FE-MODEL]. The model captures the high level properties of the FE 2649 that the CE needs to know to begin working with the FE. The class ID 2650 for this LFB Class is also assigned in [FE-MODEL]. The singular 2651 instance of this class will always exist, and will always have 2652 instance ID 0x1 within its class. It is common, although not 2653 mandatory, for a CE to fetch much of the component and capability 2654 information from this LFB instance when the CE begins controlling the 2655 operation of the FE. 2657 7.4. Semantics of Message Direction 2659 Recall: The PL provides a master(CE)-Slave(FE) relationship. The 2660 LFBs reside at the FE and are controlled by CE. 2662 When messages go from the CE, the LFB Selector (Class and instance) 2663 refers to the destination LFB selection which resides in the FE. 2665 When messages go from the FE to the CE, the LFB Selector (Class and 2666 instance) refers to the source LFB selection which resides in the FE. 2668 7.5. Association Messages 2670 The ForCES Association messages are used to establish and teardown 2671 associations between FEs and CEs. 2673 7.5.1. Association Setup Message 2675 This message is sent by the FE to the CE to setup a ForCES 2676 association between them. 2678 Message transfer direction: 2679 FE to CE 2681 Message header: 2682 The Message Type in the header is set MessageType= 2683 'AssociationSetup'. The ACK flag in the header MUST be ignored, 2684 and the association setup message always expects to get a response 2685 from the message receiver (CE), whether the setup is successful or 2686 not. The correlator field in the header is set, so that FE can 2687 correlate the response coming back from the CE correctly. The FE 2688 may set the source ID to 0 in the header to request that the CE 2689 should assign an FE ID for the FE in the setup response message. 2691 Message body: 2692 The association setup message body optionally consists of zero, 2693 one or two LFBselect TLVs, as described in Section 7.1.5. The 2694 Association Setup message only operates on the FE Object and FE 2695 Protocol LFBs, therefore, the LFB class ID in the LFBselect TLV 2696 only points to these two kinds of LFBs. 2698 The OPER-TLV in the LFBselect TLV is defined as a 'REPORT' 2699 operation. More than one component may be announced in this 2700 message using REPORT operation to let the FE declare its 2701 configuration parameters in an unsolicited manner. These may 2702 contain components suggesting values such as the FE HB Interval, 2703 or the FEID. The OPER-TLV used is defined below. 2705 OPER-TLV for Association Setup: 2707 0 1 2 3 2708 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 2709 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2710 | Type = REPORT | Length | 2711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2712 | PATH-DATA-TLV for REPORT | 2713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2715 Figure 22: OPER-TLV 2717 Type: 2718 Only one operation type is defined for the association setup 2719 message: 2721 Type = "REPORT" - this type of operation is for FE to 2722 report something to CE. 2724 PATH-DATA-TLV for REPORT: 2725 This is generically a PATH-DATA-TLV format that has been defined 2726 in section (Section 7) in the PATH-DATA BNF definition. The PATH- 2727 DATA-TLV for REPORT operation MAY contain FULLDATA-TLV(s) but 2728 SHALL NOT contain any RESULT TLV in the data format. The RESULT 2729 TLV is defined in Section 7.1.7 and the FULLDATA-TLV is defined in 2730 Section 7.1.8. 2732 To better illustrate the above PDU format, a tree structure for the 2733 format is shown below: 2735 main hdr (type = Association Setup) 2736 | 2737 | 2738 +--- T = LFBselect 2739 | | 2740 | +-- LFBCLASSID = FE object 2741 | | 2742 | | 2743 | +-- LFBInstance = 0x1 2744 | 2745 +--- T = LFBselect 2746 | 2747 +-- LFBCLASSID = FE Protocol object 2748 | 2749 | 2750 +-- LFBInstance = 0x1 2751 | 2752 +---OPER-TLV = REPORT 2753 | 2754 +-- Path-data to one or more components 2756 Figure 23: PDU Format For Association Setup Message 2758 7.5.2. Association Setup Response Message 2760 This message is sent by the CE to the FE in response to the Setup 2761 message. It indicates to the FE whether the setup is successful or 2762 not, i.e., whether an association is established. 2764 Message transfer direction: 2765 CE to FE 2767 Message Header: 2768 The Message Type in the header is set MessageType= 2769 'AssociationSetupResponse'. The ACK flag in the header MUST be 2770 ignored, and the setup response message never expects to get any 2771 more responses from the message receiver (FE). The destination 2772 ID in the header will be set to the source ID in the 2773 corresponding association setup message, unless that source ID 2774 was 0. If the corresponding source ID was 0, then the CE will 2775 assign an FE ID value and use that value for the destination ID. 2777 0 1 2 3 2778 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 2779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2780 | Type = ASRresult | Length | 2781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2782 | Association Setup Result | 2783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2785 Figure 24: ASResult OPER-TLV 2787 Type (16 bits): 2788 The type of the TLV is "ASResult". 2790 Length (16 bits): 2791 Length of the TLV including the T and L fields, in octets. 2793 Association Setup Result (32 bits): 2794 This indicates whether the setup msg was successful or whether 2795 the FE request was rejected by the CE. the defined values are: 2797 0 = success 2799 1 = FE ID invalid 2801 2 = permission denied 2803 To better illustrate the above PDU format, a tree structure for the 2804 format is shown below: 2806 main hdr (type = Association Setup Response) 2807 | 2808 | 2809 +--- T = ASResult 2811 Figure 25: PDU Format for Association Setup Repsonse Message 2813 7.5.3. Association Teardown Message 2815 This message can be sent by the FE or CE to any ForCES element to end 2816 its ForCES association with that element. 2818 Message transfer direction: 2819 CE to FE, or FE to CE (or CE to CE) 2821 Message Header: 2822 The Message Type in the header is set MessageType= 2823 "AssociationTeardown". The ACK flag MUST be ignored. The 2824 correlator field in the header MUST be set to zero and MUST be 2825 ignored by the receiver. 2827 0 1 2 3 2828 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 2829 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2830 | Type = ASTreason | Length | 2831 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2832 | Teardown Reason | 2833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2835 Figure 26: ASTreason TLV 2837 Type (16 bits): 2838 The type of the TLV is "ASTreason". 2840 Length (16 bits): 2841 Length of the TLV including the T and L fields, in octets. 2843 Teardown Reason (32 bits): 2844 This indicates the reason why the association is being 2845 terminated. Several reason codes are defined as follows. 2847 0 - normal teardown by administrator 2849 1 - error - loss of heartbeats 2851 2 - error - out of bandwidth 2853 3 - error - out of memory 2855 4 - error - application crash 2857 255 - error - other or unspecified 2859 To better illustrate the above PDU format, a tree structure for the 2860 format is shown below: 2862 main hdr (type = Association Teardown) 2863 | 2864 | 2865 +--- T = ASTreason 2867 Figure 27: PDU Format for Association Teardown Message 2869 7.6. Configuration Messages 2871 The ForCES Configuration messages are used by CE to configure the FEs 2872 in a ForCES NE and report the results back to the CE. 2874 7.6.1. Config Message 2876 This message is sent by the CE to the FE to configure LFB components 2877 in the FE. This message is also used by the CE to subscribe/ 2878 unsubscribe to LFB events. 2880 As usual, a config message is composed of a common header followed by 2881 a message body that consists of one or more TLV data format. 2882 Detailed description of the message is as below. 2884 Message transfer direction: 2885 CE to FE 2887 Message Header: 2888 The Message Type in the header is set MessageType= 'Config'. The 2889 ACK flag in the header can be set to any value defined in 2890 Section 6.1, to indicate whether or not a response from FE is 2891 expected by the message. 2893 OPER-TLV for Config: 2895 0 1 2 3 2896 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 2897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2898 | Type | Length | 2899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2900 | PATH-DATA-TLV | 2901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2903 Figure 28: OPER-TLV for Config 2905 Type: 2906 The operation type for config message. two types of operations 2907 for the config message are defined: 2909 Type = "SET" - this operation is to set LFB components 2911 Type = "SET-PROP" - this operation is to set LFB component 2912 properties 2913 Type = "DEL" - this operation to delete some LFB 2914 components 2916 Type = "COMMIT" - this operation is sent to the FE to 2917 commit in a 2pc transaction. A COMMIT TLV is an empty TLV 2918 i.e it has no "V"alue. In other words, There is a Length 2919 of 4 (which is for the header only). 2921 Type = "TRCOMP" - this operation is sent to the FE to mark 2922 the success from an NE perspective of a 2pc transaction. 2923 A TRCOMP TLV is an empty TLV i.e it has no "V"alue. In 2924 other words, There is a Length of 4 (which is for the 2925 header only). 2927 PATH-DATA-TLV: 2928 This is generically a PATH-DATA-TLV format that has been defined 2929 in section (Section 7) in the PATH-DATA BNF definition. The 2930 restriction on the use of PATH-DATA-TLV for SET/SET-PROP 2931 operation is that it MUST contain either a FULLDATA or SPARSEDATA 2932 TLV(s), but MUST NOT contain any RESULT TLV. The restriction on 2933 the use of PATH-DATA-TLV for DEL operation is it MAY contain 2934 FULLDATA or SPARSEDATA TLV(s), but MUST NOT contain any RESULT 2935 TLV. The RESULT TLV is defined in Section 7.1.7 and FULLDATA and 2936 SPARSEDATA TLVs is defined in Section 7.1.8. 2938 *Note: For Event subscription, the events will be defined by the 2939 individual LFBs. 2941 To better illustrate the above PDU format, a tree structure for the 2942 format is shown below: 2944 main hdr (type = Config) 2945 | 2946 | 2947 +--- T = LFBselect 2948 . | 2949 . +-- LFBCLASSID = target LFB class 2950 . | 2951 | 2952 +-- LFBInstance = target LFB instance 2953 | 2954 | 2955 +-- T = operation { SET } 2956 | | 2957 | +-- // one or more path targets 2958 | // associated with FULL or SPARSEDATA TLV(s) 2959 | 2960 +-- T = operation { DEL } 2961 | | 2962 | +-- // one or more path targets 2963 | 2964 +-- T = operation { COMMIT } //A COMMIT TLV is an empty TLV 2965 . 2966 . 2968 Figure 29: PDU Format for Configuration Message 2970 7.6.2. Config Response Message 2972 This message is sent by the FE to the CE in response to the Config 2973 message. It indicates whether the Config was successful or not on 2974 the FE and also gives a detailed response regarding the configuration 2975 result of each component. 2977 Message transfer direction: 2978 FE to CE 2980 Message Header: 2981 The Message Type in the header is set MessageType= 'Config 2982 Response'. The ACK flag in the header is always ignored, and the 2983 Config Response message never expects to get any further response 2984 from the message receiver (CE). 2986 OPER-TLV for Config Response: 2988 0 1 2 3 2989 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 2990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2991 | Type | Length | 2992 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2993 | PATH-DATA-TLV | 2994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2996 Figure 30: OPER-TLV for Config Response 2998 Type: 2999 The operation type for Config Response message. Two types of 3000 operations for the Config Response message are defined: 3002 Type = "SET-RESPONSE" - this operation is for the response 3003 of SET operation of LFB components 3005 Type = "SET-PROP-RESPONSE" - this operation is for the 3006 response of SET-PROP operation of LFB component properties 3008 Type = "DEL-RESPONSE" - this operation is for the response 3009 of the DELETE operation of LFB components 3011 Type = "COMMIT-RESPONSE" - this operation is sent to the 3012 CE to confirm a commit success in a 2pc transaction. A 3013 COMMIT-RESPONSE TLV MUST contain a RESULT TLV indicating 3014 success or failure. 3016 PATH-DATA-TLV: 3017 This is generically a PATH-DATA-TLV format that has been defined 3018 in section (Section 7) in the PATH-DATA BNF definition. The 3019 restriction on the use of PATH-DATA-TLV for SET-RESPONSE 3020 operation is that it MUST contain RESULT TLV(s). The restriction 3021 on the use of PATH-DATA-TLV for DEL-RESPONSE operation is it also 3022 MUST contain RESULT TLV(s). The RESULT TLV is defined in 3023 Section 7.1.7. 3025 To better illustrate the above PDU format, a tree structure for the 3026 format is shown below: 3028 main hdr (type = ConfigResponse) 3029 | 3030 | 3031 +--- T = LFBselect 3032 . | 3033 . +-- LFBCLASSID = target LFB class 3034 . | 3035 | 3036 +-- LFBInstance = target LFB instance 3037 | 3038 | 3039 +-- T = operation { SET-RESPONSE } 3040 | | 3041 | +-- // one or more path targets 3042 | // associated with FULL or SPARSEDATA TLV(s) 3043 | 3044 +-- T = operation { DEL-RESPONSE } 3045 | | 3046 | +-- // one or more path targets 3047 | 3048 +-- T = operation { COMMIT-RESPONSE } 3049 | | 3050 | +-- RESULT 3052 Figure 31: PDU Format for Configuration Response message 3054 7.7. Query Messages 3056 The ForCES query messages are used by the CE to query LFBs in the FE 3057 for informations like LFB components, capabilities, statistics, etc. 3058 Query Messages include the Query Message and the Query Response 3059 Message. 3061 7.7.1. Query Message 3063 A Query message is composed of a common header and a message body 3064 that consists of one or more TLV data format. Detailed description 3065 of the message is as below. 3067 Message transfer direction: 3068 from CE to FE 3070 Message Header: 3071 The Message Type in the header is set to MessageType= 'Query'. 3072 The ACK flag in the header is always ignored, and a full response 3073 for a query message is always expected. The Correlator field in 3074 the header is set, so that the CE can locate the response back 3075 from FE correctly. 3077 OPER-TLV for Query: 3079 0 1 2 3 3080 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 3081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3082 | Type = GET/GET-PROP | Length | 3083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3084 | PATH-DATA-TLV for GET/GET-PROP | 3085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3087 Figure 32: TLV for Query 3089 Type: 3090 The operation type for query. Two operation types are defined: 3092 Type = "GET" - this operation is to request to get LFB 3093 components. 3095 Type = "GET-PROP" - this operation is to request to get 3096 LFB components. 3098 PATH-DATA-TLV for GET/GET-PROP: 3099 This is generically a PATH-DATA-TLV format that has been defined 3100 in section (Section 7) in the PATH-DATA BNF definition. The 3101 restriction on the use of PATH-DATA-TLV for GET/GET-PROP 3102 operation is it MUST NOT contain any SPARSEDATA or FULLDATA TLV 3103 and RESULT TLV in the data format. 3105 To better illustrate the above PDU format, a tree structure for the 3106 format is shown below: 3108 main hdr (type = Query) 3109 | 3110 | 3111 +--- T = LFBselect 3112 . | 3113 . +-- LFBCLASSID = target LFB class 3114 . | 3115 | 3116 +-- LFBInstance = target LFB instance 3117 | 3118 | 3119 +-- T = operation { GET } 3120 | | 3121 | +-- // one or more path targets 3122 | 3123 +-- T = operation { GET } 3124 . | 3125 . +-- // one or more path targets 3126 . 3128 Figure 33: PDU Format for Query Message 3130 7.7.2. Query Response Message 3132 When receiving a Query message, the receiver should process the 3133 message and come up with a query result. The receiver sends the 3134 query result back to the message sender by use of the Query Response 3135 Message. The query result can be the information being queried if 3136 the query operation is successful, or can also be error codes if the 3137 query operation fails, indicating the reasons for the failure. 3139 A Query Response message is also composed of a common header and a 3140 message body consisting of one or more TLVs describing the query 3141 result. Detailed description of the message is as below. 3143 Message transfer direction: 3144 from FE to CE 3146 Message Header: 3147 The Message Type in the header is set to MessageType= 3148 'QueryResponse'. The ACK flag in the header is ignored. As a 3149 response itself, the message does not expect a further response. 3151 OPER-TLV for Query Response: 3153 0 1 2 3 3154 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 3155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3156 |Type = GET-RESPONSE/GET-PROP-RESPONSE| Length | 3157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3158 | PATH-DATA-TLV for GET-RESPONSE/GET-PROP-RESPONSE | 3159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3161 Figure 34: TLV for Query Response 3163 Type: 3164 The operation type for query response. One operation type is 3165 defined: 3167 Type = "GET-RESPONSE" - this operation is to response to 3168 get operation of LFB components. 3170 Type = "GET-PROP-RESPONSE" - this operation is to response 3171 to GET-PROP operation of LFB components. 3173 PATH-DATA-TLV for GET-RESPONSE/GET-PROP-RESPONSE: 3174 This is generically a PATH-DATA-TLV format that has been defined 3175 in section (Section 7) in the PATH-DATA BNF definition. The 3176 PATH-DATA-TLV for GET-RESPONSE operation MAY contain SPARSEDATA 3177 TLV, FULLDATA TLV and/or RESULT TLV(s) in the data encoding. The 3178 RESULT TLV is defined in Section 7.1.7 and the SPARSEDATA and 3179 FULLDATA TLVs are defined in Section 7.1.8. 3181 To better illustrate the above PDU format, a tree structure for the 3182 format is shown below: 3184 main hdr (type = QueryResponse) 3185 | 3186 | 3187 +--- T = LFBselect 3188 . | 3189 . +-- LFBCLASSID = target LFB class 3190 . | 3191 | 3192 +-- LFBInstance = target LFB instance 3193 | 3194 | 3195 +-- T = operation { GET-RESPONSE } 3196 | | 3197 | +-- // one or more path targets 3198 | 3199 +-- T = operation { GET-PROP-RESPONSE } 3200 . | 3201 . +-- // one or more path targets 3202 . 3204 Figure 35: PDU Format for Query Response Message 3206 7.8. Event Notification Message 3208 Event Notification Message is used by FE to asynchronously notify CE 3209 of events that happen in the FE. 3211 All events that can be generated in an FE are subscribable by the CE. 3212 The CE can subscribe to an event via a Config message with SET-PROP 3213 operation, where the included path specifies the event, as defined by 3214 the LFB Library and described by the FE Model. 3216 As usual, an Event Notification Message is composed of a common 3217 header and a message body that consists of one or more TLV data 3218 format. Detailed description of the message is as below. 3220 Message Transfer Direction: 3221 FE to CE 3223 Message Header: 3224 The Message Type in the message header is set to 3225 MessageType = 'EventNotification'. The ACK flag in the header 3226 MUST be ignored by the CE, and the event notification message does 3227 not expect any response from the receiver. 3229 OPER-TLV for Event Notification: 3231 0 1 2 3 3232 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 3233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3234 | Type = REPORT | Length | 3235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3236 | PATH-DATA-TLV for REPORT | 3237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3239 Figure 36: TLV for Event Notification 3241 Type: 3242 Only one operation type is defined for the event notification 3243 message: 3245 Type = "REPORT" - this type of operation is for FE to 3246 report something to CE. 3248 PATH-DATA-TLV for REPORT: 3249 This is generically a PATH-DATA-TLV format that has been defined 3250 in section (Section 7) in the PATH-DATA BNF definition. The PATH- 3251 DATA-TLV for REPORT operation MAY contain FULLDATA or SPARSEDATA 3252 TLV(s) but MUST NOT contain any RESULT TLV in the data format. 3254 To better illustrate the above PDU format, a tree structure for the 3255 format is shown below: 3257 main hdr (type = Event Notification) 3258 | 3259 | 3260 +--- T = LFBselect 3261 | 3262 +-- LFBCLASSID = target LFB class 3263 | 3264 | 3265 +-- LFBInstance = target LFB instance 3266 | 3267 | 3268 +-- T = operation { REPORT } 3269 | | 3270 | +-- // one or more path targets 3271 | // associated with FULL/SPARSE DATA TLV(s) 3272 +-- T = operation { REPORT } 3273 . | 3274 . +-- // one or more path targets 3275 . // associated with FULL/SPARSE DATA TLV(s) 3277 Figure 37: PDU Format for Event Notification Message 3279 7.9. Packet Redirect Message 3281 A packet Redirect message is used to transfer data packets between CE 3282 and FE. Usually these data packets are control packets but they may 3283 be just data-path packets which need further (exception or high- 3284 touch) processing. It is also feasible that this message carries no 3285 data packets and rather just metadata. 3287 The Packet Redirect message data format is formated as follows: 3289 Message Direction: 3290 CE to FE or FE to CE 3292 Message Header: 3293 The Message Type in the header is set to MessageType= 3294 'PacketRedirect'. 3296 Message Body: 3297 This consists of one or more TLVs that contain or describe the 3298 packet being redirected. The TLV is specifically a Redirect TLV 3299 (with the TLV Type="Redirect"). Detailed data format of a 3300 Redirect TLV for packet redirect message is as below: 3302 0 1 2 3 3303 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 3304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3305 | Type = Redirect | Length | 3306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3307 | Meta Data TLV | 3308 . . 3309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3310 | Redirect Data TLV | 3311 . . 3312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3314 Figure 38: Redirect_Data TLV 3316 Meta Data TLV: 3317 This is a TLV that specifies meta-data associated with followed 3318 redirected data. The TLV is as follows: 3320 0 1 2 3 3321 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 3322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3323 | Type = METADATA | Length | 3324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3325 | Meta Data ILV | 3326 . . 3327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3328 ~ ... ~ 3329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3330 | Meta Data ILV | 3331 . . 3332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3334 Figure 39: METADATA TLV 3336 Meta Data ILV: 3337 This is an Identifier-Length-Value format that is used to describe 3338 one meta data. The ILV has the format as: 3340 0 1 2 3 3341 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 3342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3343 | Meta Data ID | 3344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3345 | Length | 3346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3347 | Meta Data Value | 3348 . . 3349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3351 Figure 40: Meta Data ILV 3353 Where, Meta Data ID is an identifier for the meta data, which is 3354 statically assigned by the LFB definition. 3356 Redirect Data TLV 3357 This is a TLV describing one packet of data to be directed via the 3358 redirect operation. The TLV format is as follows: 3360 0 1 2 3 3361 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 3362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3363 | Type = REDIRECTDATA | Length | 3364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3365 | Redirected Data | 3366 . . 3367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3369 Figure 41: Redirect Data TLV 3371 Redirected Data: 3372 This field contains the packet that is to be redirected in network 3373 byte order. The packet should be 32-bits aligned as is the data 3374 for all TLVs. The metadata infers what kind of packet is carried 3375 in value field and therefore allows for easy decoding of data 3376 encapsulated 3378 To better illustrate the above PDU format, a tree structure for the 3379 format is shown below: 3381 main hdr (type = PacketRedirect) 3382 | 3383 | 3384 +--- T = Redirect 3385 . | 3386 . +-- T = METADATA 3387 | | 3388 | +-- Meta Data ILV 3389 | | 3390 | +-- Meta Data ILV 3391 | . 3392 | . 3393 | 3394 +-- T = REDIRECTDATA 3395 | 3396 +-- // Redirected Data 3398 Figure 42: PDU Format for Packet Redirect Message 3400 7.10. Heartbeat Message 3402 The Heartbeat (HB) Message is used for one ForCES element (FE or CE) 3403 to asynchronously notify one or more other ForCES elements in the 3404 same ForCES NE on its liveness. Section 4.3.3 describes the traffic- 3405 sensitive approach used. 3407 A Heartbeat Message is sent by a ForCES element periodically. The 3408 parameterization and policy definition for heartbeats for an FE is 3409 managed as components of the FE Protocol Object LFB, and can be set 3410 by CE via a Config message. The Heartbeat message is a little 3411 different from other protocol messages in that it is only composed of 3412 a common header, with the message body left empty. A detailed 3413 description of the message is as below. 3415 Message Transfer Direction: 3416 FE to CE or CE to FE 3418 Message Header: 3419 The Message Type in the message header is set to MessageType = 3420 'Heartbeat'. Section 4.3.3 describes the HB mechanisms used. 3421 The ACK flag in the header MUST be set to either 'NoACK' or 3422 'AlwaysACK' when the HB is sent. 3424 * When set to 'NoACK', the HB is not soliciting for a response. 3426 * When set to 'AlwaysACK', the HB Message sender is always 3427 expecting a response from its receiver. According the HB 3428 policies defined in Section 7.3.1, only the CE can send such 3429 an HB message to query FE liveness. For simplicity and 3430 because of the minimal nature of the HB message, the response 3431 to a HB message is another HB message, i.e., no specific HB 3432 response message is defined. Whenever an FE receives a HB 3433 message marked with 'AlwaysACK' from the CE, the FE MUST send 3434 a HB message back immediately. The HB message sent by the FE 3435 in response to the 'AlwasyACK' MUST modify the source and 3436 destination IDs so that the ID of the FE is the source ID and 3437 the CE ID of the sender is the destination ID, and MUST 3438 change the ACK information to 'NoACK'. A CE MUST NOT respond 3439 to an HB message with 'AlwasyACK' set. 3441 * When set to anything else other than 'NoACK' or 'AlwaysACK', 3442 the HB Message is treated as if it was a 'NoACK'. 3444 The correlator field in the HB message header SHOULD be set 3445 accordingly when a response is expected so that a receiver can 3446 correlate the response correctly. The correlator field MAY be 3447 ignored if no response is expected. 3449 Message Body: 3450 The message body is empty for the Heartbeat Message. 3452 8. High Availability Support 3454 The ForCES protocol provides mechanisms for CE redundancy and 3455 failover, in order to support High Availability as defined in 3456 [RFC3654]. FE redundancy and FE to FE interaction is currently out 3457 of scope of this document. There can be multiple redundant CEs and 3458 FEs in a ForCES NE. However, at any one time only one primary CE can 3459 control the FEs though there can be multiple secondary CEs. The FE 3460 and the CE PL are aware of the primary and secondary CEs. This 3461 information (primary, secondary CEs) is configured in the FE and in 3462 the CE PLs during pre-association by the FEM and the CEM 3463 respectively. Only the primary CE sends control messages to the FEs. 3465 8.1. Relation with the FE Protocol 3467 High Availability parameterization in an FE is driven by configuring 3468 the FE Protocol Object LFB (refer to Appendix B and Section 7.3.1). 3469 The FE Heartbeat Interval, CE Heartbeat Dead Interval, and CE 3470 Heartbeat policy help in detecting connectivity problems between an 3471 FE and CE. The CE Failover policy defines the reaction on a detected 3472 failure. 3474 Figure 43 extends the state machine illustrated in Figure 4 to allow 3475 for new states that facilitate connection recovery. 3477 (CE issues Teardown || +-----------------+ 3478 Lost association) && | Pre-Association | 3479 CE failover policy = 0 | (Association | 3480 +------------>-->-->| in +<----+ 3481 | | progress) | | 3482 | CE Issues +--------+--------+ | 3483 | Association | | CFTI 3484 | Setup V | timer 3485 | ___________________+ | expires 3486 | | | 3487 | V ^ 3488 +-+-----------+ +-------+-----+ 3489 | | | Not | 3490 | | (CE issues Teardown || | Associated | 3491 | | Lost association) && | | 3492 | Associated | CE Failover Policy = 1 | (May | 3493 | | | Continue | 3494 | |---------->------->------>| Forwarding)| 3495 | | | | 3496 +-------------+ +-------------+ 3497 ^ V 3498 | | 3499 | CE Issues | 3500 | Association | 3501 | Setup | 3502 +_________________________________________+ 3504 Figure 43: FE State Machine considering HA 3506 Section 4.2 describes transitions between the Pre-association, 3507 associated and not associated states. 3509 When communication fails between the FE and CE (which can be caused 3510 by either the CE or link failure but not FE related), either the TML 3511 on the FE will trigger the FE PL regarding this failure or it will be 3512 detected using the HB messages between FEs and CEs. The 3513 communication failure, regardless of how it is detected, MUST be 3514 considered as a loss of association between the CE and corresponding 3515 FE. 3517 If the FE's FEPO CE Failover Policy is configured to mode 0 (the 3518 default), it will immediately transition to the pre-association 3519 phase. This means that if association is again established, all FE 3520 state will need to be re-established. 3522 If the FE's FEPO CE Failover Policy is configured to mode 1, it 3523 indicates that the FE is capable of HA restart recovery. In such a 3524 case, the FE transitions to the not associated state and the CEFTI 3525 timer is started. The FE MAY continue to forward packets during this 3526 state. It MAY also recycle through any configured secondary CEs in a 3527 round-robin fashion. It first adds its primary CE to the tail of 3528 backup CEs and sets its primary CE to be the first secondary. It 3529 then attempts to associate with the CE designated as the new primary 3530 CE. If it fails to re-associate with any CE and the CEFTI expires, 3531 the FE then transitions to the Pre-association state. 3533 If the FE, while in the not associated state, manages to reconnect to 3534 a new primary CE before CEFTI expires it transitions to the 3535 Associated state. Once re-associated, the FE tries to recover any 3536 state that may have been lost during the not associated state. How 3537 the FE achieves re-synchronizes it state is out of scope for this 3538 document. 3540 Figure 44 below illustrates the Forces message sequences that the FE 3541 uses to recover the connection. 3543 FE CE Primary CE Secondary 3544 | | | 3545 | Asso Estb,Caps exchg | | 3546 1 |<--------------------->| | 3547 | | | 3548 | All msgs | | 3549 2 |<--------------------->| | 3550 | | | 3551 | | | 3552 | FAILURE | 3553 | | 3554 | Asso Estb,Caps exchange | 3555 3 |<------------------------------------------>| 3556 | | 3557 | Event Report (pri CE down) | 3558 4 |------------------------------------------->| 3559 | | 3560 | All Msgs | 3561 5 |<------------------------------------------>| 3563 Figure 44: CE Failover for Report Primary Mode 3565 A CE-to-CE synchronization protocol would be needed to support fast 3566 failover as well as to address some of the corner cases, however this 3567 will not be defined by the ForCES protocol as it is out of scope for 3568 this specification. 3570 An explicit message (a Config message setting Primary CE component in 3571 ForCES Protocol object) from the primary CE, can also be used to 3572 change the Primary CE for an FE during normal protocol operation. 3574 Also note that the FEs in a ForCES NE could also use a multicast CE 3575 ID, i.e., they could be associated with a group of CEs (this assumes 3576 the use of a CE-CE synchronization protocol, which is out of scope 3577 for this specification). In this case, the loss of association would 3578 mean that communication with the entire multicast group of CEs has 3579 been lost. The mechanisms described above will apply for this case 3580 as well during the loss of association. If, however, the secondary 3581 CE was also using the multicast CE ID that was lost, then the FE will 3582 need to form a new association using a different CE ID. If the 3583 capability exists, the FE MAY first attempt to form a new association 3584 with original primary CE using a different non multicast CE ID. 3586 8.2. Responsibilities for HA 3588 TML Level: 3590 1. The TML controls logical connection availability and failover. 3592 2. The TML also controls peer HA management. 3594 At this level, control of all lower layers, for example transport 3595 level (such as IP addresses, MAC addresses etc) and associated links 3596 going down are the role of the TML. 3598 PL Level: 3599 All other functionality, including configuring the HA behavior during 3600 setup, the CE IDs used to identify primary and secondary CEs, 3601 protocol messages used to report CE failure (Event Report), Heartbeat 3602 messages used to detect association failure, messages to change the 3603 primary CE (Config), and other HA related operations described 3604 before, are the PL responsibility. 3606 To put the two together, if a path to a primary CE is down, the TML 3607 would take care of failing over to a backup path, if one is 3608 available. If the CE is totally unreachable then the PL would be 3609 informed and it would take the appropriate actions described before. 3611 9. Security Considerations 3613 ForCES architecture identifies several levels of security in 3614 [RFC3746]. ForCES PL uses security services provided by the ForCES 3615 TML. The TML provides security services such as endpoint 3616 authentication service, message authentication service and 3617 confidentiality service. Endpoint authentication service is invoked 3618 at the time of the pre-association connection establishment phase and 3619 message authentication is performed whenever the FE or CE receives a 3620 packet from its peer. 3622 The following are the general security mechanisms that need to be in 3623 place for ForCES PL. 3625 o Security mechanisms are session controlled - that is, once the 3626 security is turned on depending upon the chosen security level (No 3627 Security, Authentication, Confidentiality), it will be in effect 3628 for the entire duration of the session. 3630 o An operator should configure the same security policies for both 3631 primary and backup FEs and CEs (if available). This will ensure 3632 uniform operations and avoid unnecessary complexity in policy 3633 configuration. 3635 9.1. No Security 3637 When "No security" is chosen for ForCES protocol communication, both 3638 endpoint authentication and message authentication service needs to 3639 be performed by ForCES PL. Both these mechanism are weak and do not 3640 involve cryptographic operation. An operator can choose "No 3641 Security" level when the ForCES protocol endpoints are within a 3642 single box, for example. 3644 In order to have interoperable and uniform implementation across 3645 various security levels, each CE and FE endpoint MUST implement this 3646 level. 3648 9.1.1. Endpoint Authentication 3650 Each CE and FE PL maintains a list of associations as part its of 3651 configuration. This is done via the CEM and FEM interfaces. An FE 3652 MUST connect to only those CEs that are configured via the FEM; 3653 similarly, a CE should accept the connection and establish 3654 associations for the FEs which are configured via the CEM. The CE 3655 should validate the FE identifier before accepting the connections 3656 during the pre-association phase. 3658 9.1.2. Message authentication 3660 When a CE or FE initiates a message, the receiving endpoint MUST 3661 validate the initiator of the message by checking the common header 3662 CE or FE identifiers. This will ensure proper protocol functioning. 3663 This extra processing step is recommend even when underlying provides 3664 TLM layer security services exist. 3666 9.2. ForCES PL and TML security service 3668 This section is applicable if an operator wishes to use the TML 3669 security services. A ForCES TML MUST support one or more security 3670 services such as endpoint authentication service, message 3671 authentication service, and confidentiality service, as part of TML 3672 security layer functions. It is the responsibility of the operator 3673 to select an appropriate security service and configure security 3674 policies accordingly. The details of such configuration are outside 3675 the scope of the ForCES PL and are dependent on the type of transport 3676 protocol and the nature of the connection. 3678 All these configurations should be done prior to starting the CE and 3679 FE. 3681 When certificates-based authentication is being used at the TML, the 3682 certificate can use a ForCES-specific naming structure as certificate 3683 names and, accordingly, the security policies can be configured at 3684 the CE and FE. 3686 9.2.1. Endpoint authentication service 3688 When TML security services are enabled, the ForCES TML performs 3689 endpoint authentication. Security association is established between 3690 CE and FE and is transparent to the ForCES PL. 3692 9.2.2. Message authentication service 3694 This is a TML specific operation and is transparent to the ForCES PL. 3695 For details, refer to Section 5. 3697 9.2.3. Confidentiality service 3699 This is a TML specific operation and is transparent to the ForCES PL. 3700 For details, refer to Section 5. 3702 10. Acknowledgements 3704 The authors of this draft would like to acknowledge and thank the 3705 ForCES Working Group and especially the following: Furquan Ansari, 3706 Alex Audu, Steven Blake, Shuchi Chawla, Alan DeKok, Ellen M. 3707 Deleganes, Xiaoyi Guo, Yunfei Guo, Evangelos Haleplidis, Joel M. 3708 Halpern (who should probably be listed among the authors), Zsolt 3709 Haraszti, Fenggen Jia, John C. Lin, Alistair Munro, Jeff Pickering, 3710 T. Sridhlar, Guangming Wang, Chaoping Wu, and Lily L. Yang, for their 3711 contributions. We would also like to thank David Putzolu, and 3712 Patrick Droz for their comments and suggestions on the protocol and 3713 for their infinite patience. We would also like to thank Sue Hares 3714 and Alia Atlas for extensive reviews of the document. 3716 Alia Atlas has done a wonderful job of shaping the draft to make it 3717 more readable by providing the IESG feedback. 3719 The editors have used the xml2rfc [RFC2629] tools in creating this 3720 document and are very grateful for the existence and quality of these 3721 tools. The editor is also grateful to Elwyn Davies for his help in 3722 correcting the XML source of this document. 3724 11. References 3726 11.1. Normative References 3728 [FE-MODEL] 3729 Yang, L., Halpern, J., Gopal, R., DeKok, A., Haraszti, Z., 3730 and S. Blake, "ForCES Forwarding Element Model", 3731 Feb. 2005. 3733 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3734 Requirement Levels", BCP 14, RFC 2119, March 1997. 3736 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3737 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 3738 October 1998. 3740 11.2. Informational References 3742 [2PCREF] Gray, J., "Notes on database operating systems. In 3743 Operating Systems: An Advanced Course. Lecture Notes in 3744 Computer Science, Vol. 60, pp. 394-481, Springer-Verlag", 3745 1978. 3747 [ACID] Haerder, T. and A. Reuter, "Principles of Transaction- 3748 Orientated Database Recovery", 1983. 3750 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 3751 June 1999. 3753 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 3754 of IP Control and Forwarding", RFC 3654, November 2003. 3756 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 3757 "Forwarding and Control Element Separation (ForCES) 3758 Framework", RFC 3746, April 2004. 3760 Appendix A. IANA Considerations 3762 Following the policies outlined in "Guidelines for Writing an IANA 3763 Considerations Section in RFCs" (RFC 2434 [RFC2434]), the following 3764 name spaces are defined in ForCES. 3766 o Message Type Name Space Section 7 3768 o Operation Type Name Space Section 7.1.6 3770 o Header Flags Section 6.1 3772 o TLV Type Section 7 3774 o TLV Result Values Section 7.1.7 3776 o LFB Class ID Section 7.1.5 3778 o Result: Association Setup Response Section 7.5.2 3780 o Reason: Association Teardown Message Section 7.5.3 3782 A.1. Message Type Name Space 3784 The Message Type is an 8 bit value. The following is the guideline 3785 for defining the Message Type namespace 3787 Message Types 0x00 - 0x0F 3788 Message Types in this range are part of the base ForCES Protocol. 3789 Message Types in this range are allocated through an IETF 3790 consensus action. [RFC2434] 3791 Values assigned by this specification: 3793 0x00 Reserved 3794 0x01 AssociationSetup 3795 0x02 AssociationTeardown 3796 0x03 Config 3797 0x04 Query 3798 0x05 EventNotification 3799 0x06 PacketRedirect 3800 0x07 - 0x0E Reserved 3801 0x0F Hearbeat 3802 0x11 AssociationSetupRepsonse 3803 0x12 Reserved 3804 0x13 ConfigRepsonse 3805 0x14 QueryResponse 3807 Message Types 0x20 - 0x7F 3808 Message Types in this range are Specification Required [RFC2434] 3809 Message Types using this range must be documented in an RFC or 3810 other permanent and readily available reference. 3812 Message Types 0x80 - 0xFF 3813 Message Types in this range are reserved for vendor private 3814 extensions and are the responsibility of individual vendors. IANA 3815 management of this range of the Message Type Name Space is 3816 unnecessary. 3818 A.2. Operation Selection 3820 The Operation Selection (OPER-TLV) name space is 16 bits long. The 3821 following is the guideline for managing the OPER-TLV Name Space. 3823 OPER-TLV Type 0x0000-0x00FF 3824 OPER-TLV Types in this range are allocated through an IETF 3825 consensus process. [RFC2434]. 3826 Values assigned by this specification: 3828 0x0000 Reserved 3829 0x0001 SET 3830 0x0002 SET-PROP 3831 0x0003 SET-RESPONSE 3832 0x0004 SET-PROP-RESPONSE 3833 0x0005 DEL 3834 0x0006 DEL-RESPONSE 3835 0x0007 GET 3836 0x0008 GET-PROP 3837 0x0009 GET-RESPONSE 3838 0x000A GET-PROP-RESPONSE 3839 0x000B REPORT 3840 0x000C COMMIT 3841 0x000D COMMIT-RESPONSE 3842 0x000E TRCOMP 3844 OPER-TLV Type 0x0100-0x7FFF 3845 OPER-TLV Types using this range must be documented in an RFC or 3846 other permanent and readily available reference. [RFC2434]. 3848 OPER-TLV Type 0x8000-0xFFFF 3849 OPER-TLV Types in this range are reserved for vendor private 3850 extensions and are the responsibility of individual vendors. IANA 3851 management of this range of the OPER-TLV Type Name Space is 3852 unnecessary. 3854 A.3. Header Flags 3856 The Header flag field is 32 bits long. Header flags are part of 3857 the ForCES base protocol. Header flags are allocated through an 3858 IETF consensus action [RFC2434]. 3860 A.4. TLV Type Name Space 3862 The TLV Type name space is 16 bits long. The following is the 3863 guideline for managing the TLV Type Name Space. 3865 TLV Type 0x0000-0x00FF 3866 TLV Types in this range are allocated through an IETF consensus 3867 process. [RFC2434]. 3868 Values assigned by this specification: 3870 0x0000 Reserved 3871 0x0001 REDIRECT-TLV 3872 0x0010 ASResult-TLV 3873 0x0011 ASTreason-TLV 3874 0x1000 LFBselect-TLV 3875 0x0110 PATH-DATA-TLV 3876 0x0111 KEYINFO-TLV 3877 0x0112 FULLDATA-TLV 3878 0x0113 SPARSEDATA-TLV 3879 0x0114 RESULT-TLV 3880 0x0115 METADATA-TLV 3881 0x0116 REDIRECTDATA-TLV 3883 TLV Type 0x0200-0x7FFF 3884 TLV Types using this range must be documented in an RFC or other 3885 permanent and readily available reference [RFC2434]. 3887 TLV Type 0x8000-0xFFFF 3888 TLV Types in this range are reserved for vendor private extensions 3889 and are the responsibility of individual vendors. IANA management 3890 of this range of the TLV Type Name Space is unnecessary. 3892 A.5. Result-TLV Result Values 3894 The RESULT-TLV RTesult Value is an 8 bit value. 3896 0x00 E_SUCCESS 3897 0x01 E_INVALID_HEADER 3898 0x02 E_LENGTH_MISMATCH 3899 0x03 E_VERSION_MISMATCH 3900 0x04 E_INVALID_DESTINATION_PID 3901 0x05 E_LFB_UNKNOWN 3902 0x06 E_LFB_NOT_FOUND 3903 0x07 E_LFB_INSTANCE_ID_NOT_FOUND 3904 0x08 E_INVALID_PATH 3905 0x09 E_COMPONENT_DOES_NOT_EXIST 3906 0x0A E_EXISTS 3907 0x0B E_NOT_FOUND 3908 0x0C E_READ_ONLY 3909 0x0D E_INVALID_ARRAY_CREATION 3910 0x0E E_VALUE_OUT_OF_RANGE 3911 0x0F E_CONTENTS_TOO_LONG 3912 0x10 E_INVALID_PARAMETERS 3913 0x11 E_INVALID_MESSAGE_TYPE 3914 0x12 E_E_INVALID_FLAGS 3915 0x13 E_INVALID_TLV 3916 0x14 E_EVENT_ERROR 3917 0x15 E_NOT_SUPPORTED 3918 0x16 E_MEMORY_ERROR 3919 0x17 E_INTERNAL_ERROR 3920 0x18-0xFE Reserved 3921 0xFF E_UNSPECIFIED_ERROR 3923 All values not assigned in this specification are designated as 3924 Assignment by Expert review. 3926 A.6. Association Setup Response 3928 The Association Setup Response name space is 32 bits long. The 3929 following is the guideline for managing the Association Setup 3930 Response Name Space. 3932 Association Setup Response 0x0000-0x00FF 3933 Association Setup Responses in this range are allocated through an 3934 IETF consensus process [RFC2434]. 3935 Values assigned by this specification: 3937 0x0000 Success 3938 0x0001 FE ID Invalid 3939 0x0002 Permission Denied 3941 Association Setup Response 0x0100-0x0FFF 3942 Association Setup Responses in this range are Specification 3943 Required [RFC2434] Values using this range must be documented in 3944 an RFC or other permanent and readily available reference 3945 [RFC2434]. 3947 Association Setup Response 0x1000-0xFFFFFFFFF 3948 Association Setup Responses in this range are reserved for vendor 3949 private extensions and are the responsibility of individual 3950 vendors. IANA management of this range of the Association Setup 3951 Responses Name Space is unnecessary. 3953 A.7. Association Teardown Message 3955 The Association Teardown Message name space is 32 bits long. The 3956 following is the guideline for managing the Association Teardown 3957 Message Name Space. 3959 Association Teardown Message 0x00000000-0x0000FFFF 3960 Association Teardown Messages in this range are allocated through 3961 an IETF consensus process [RFC2434]. 3962 Values assigned by this specification: 3964 0x00000000 Normal - Teardown by Administrator 3965 0x00000001 Error - loss of heartbeats 3966 0x00000002 Error - loss of bandwidth 3967 0x00000003 Error - Out of Memory 3968 0x00000004 Error - Application Crash 3969 0x000000FF Error - Unspecified 3971 Association Teardown Message 0x00010000-0x7FFFFFFF 3972 Association Teardown Messages in this range are Specification 3973 Required [RFC2434] Association Teardown Messages using this range 3974 must be documented in an RFC or other permanent and readily 3975 available references. [RFC2434]. 3977 Association Teardown Message 0x80000000-0xFFFFFFFFF 3978 Association Teardown Messages in this range are reserved for 3979 vendor private extensions and are the responsibility of individual 3980 vendors. IANA management of this range of the Association 3981 Teardown Message Name Space is unnecessary. 3983 Appendix B. ForCES Protocol LFB schema 3985 The schema described below conforms to the LFB schema described in 3986 ForCES Model draft. [FE-MODEL] 3988 Section 7.3.1 describes the details of the different components 3989 defined in this definition. 3991 3996 3997 3998 3999 CEHBPolicyValues 4000 4001 The possible values of CE heartbeat policy 4002 4003 4004 uchar 4005 4006 4007 CEHBPolicy0 4008 4009 The CE heartbeat policy 0 4010 4011 4012 4013 CEHBPolicy1 4014 4015 The CE heartbeat policy 1 4016 4017 4018 4019 4020 4022 4023 FEHBPolicyValues 4024 4025 The possible values of FE heartbeat policy 4026 4027 4028 uchar 4029 4030 4031 FEHBPolicy0 4032 4033 The FE heartbeat policy 0 4034 4035 4036 4037 FEHBPolicy1 4038 4039 The FE heartbeat policy 1 4040 4041 4042 4043 4044 4046 4047 FERestartPolicyValues 4048 4049 The possible values of FE restart policy 4050 4051 4052 uchar 4053 4054 4055 FERestartPolicy0 4056 4057 The FE restart policy 0 4058 4059 4060 4061 4062 4064 4065 CEFailoverPolicyValues 4066 4067 The possible values of CE failover policy 4068 4069 4070 uchar 4071 4072 4073 CEFailoverPolicy0 4074 4075 The CE failover policy 0 4076 4077 4079 4080 CEFailoverPolicy1 4081 4082 The CE failover policy 1 4083 4084 4085 4086 4087 4089 4090 FEHACapab 4091 4092 The supported HA features 4093 4094 4095 uchar 4096 4097 4098 GracefullRestart 4099 4100 The FE supports Graceful Restart 4101 4102 4103 4104 HA 4105 4106 The FE supports HA 4107 4108 4109 4110 4111 4112 4114 4115 4116 FEPO 4117 4118 The FE Protocol Object 4119 4120 1.0 4122 4123 4124 CurrentRunningVersion 4125 Currently running ForCES version 4126 u8 4128 4129 4130 FEID 4131 Unicast FEID 4132 uint32 4133 4134 4135 MulticastFEIDs 4136 4137 the table of all multicast IDs 4138 4139 4140 uint32 4141 4142 4143 4144 CEHBPolicy 4145 4146 The CE Heartbeat Policy 4147 4148 CEHBPolicyValues 4149 4150 4151 CEHDI 4152 4153 The CE Heartbeat Dead Interval in millisecs 4154 4155 uint32 4156 4157 4158 FEHBPolicy 4159 4160 The FE Heartbeat Policy 4161 4162 FEHBPolicyValues 4163 4164 4165 FEHI 4166 4167 The FE Heartbeat Interval in millisecs 4168 4169 uint32 4170 4171 4172 CEID 4173 4174 The Primary CE this FE is associated with 4175 4176 uint32 4177 4178 4179 BackupCEs 4180 4181 The table of all backup CEs other than the primary 4182 4183 4184 uint32 4185 4186 4187 4188 CEFailoverPolicy 4189 4190 The CE Failover Policy 4191 4192 CEFailoverPolicyValues 4193 4195 4196 CEFTI 4197 4198 The CE Failover Timeout Interval in millisecs 4199 4200 uint32 4201 4202 4203 FERestartPolicy 4204 4205 The FE Restart Policy 4206 4207 FERestartPolicyValues 4208 4209 4210 LastCEID 4211 4212 The Primary CE this FE was last associated with 4213 4214 uint32 4215 4216 4218 4219 4220 SupportableVersions 4221 4222 the table of ForCES versions that FE supports 4223 4224 4225 u8 4226 4227 4228 4229 HACapabilities 4230 4231 the table of HA capabilities the FE supports 4232 4233 4234 FEHACapab 4235 4236 4237 4239 4240 4241 PrimaryCEDown 4242 4243 The pimary CE has changed 4244 4245 4246 LastCEID 4247 4248 4249 4250 4251 LastCEID 4252 4253 4254 4255 4257 4258 4259 4261 B.1. Capabilities 4263 Supportable Versions enumerates all ForCES versions that an FE 4264 supports. 4266 FEHACapab enumerates the HA capabilities of the FE. If the FE is not 4267 capable of Graceful restarts or HA, then it will not be able to 4268 participate in HA as described in Section 8.1 4270 B.2. Components 4272 All Components are explained in Section 7.3.1. 4274 Appendix C. Data Encoding Examples 4276 In this section a few examples of data encoding are discussed. these 4277 example, however, do not show any padding. 4279 ========== 4280 Example 1: 4281 ========== 4283 Structure with three fixed-lengthof, mandatory fields. 4285 struct S { 4286 uint16 a 4287 uint16 b 4288 uint16 c 4289 } 4291 (a) Describing all fields using SPARSEDATA 4293 Path-Data TLV 4294 Path to an instance of S ... 4295 SPARSEDATA TLV 4296 ComponentIDof(a), lengthof(a), valueof(a) 4297 ComponentIDof(b), lengthof(b), valueof(b) 4298 ComponentIDof(c), lengthof(c), valueof(c) 4300 (b) Describing a subset of fields 4302 Path-Data TLV 4303 Path to an instance of S ... 4304 SPARSEDATA TLV 4305 ComponentIDof(a), lengthof(a), valueof(a) 4306 ComponentIDof(c), lengthof(c), valueof(c) 4308 Note: Even though there are non-optional components in structure S, 4309 since one can uniquely identify components, one can selectively send 4310 component of structure S (eg in the case of an update from CE to FE). 4312 (c) Describing all fields using a FULLDATA TLV 4314 Path-Data TLV 4315 Path to an instance of S ... 4316 FULLDATA TLV 4317 valueof(a) 4318 valueof(b) 4319 valueof(c) 4321 ========== 4322 Example 2: 4323 ========== 4325 Structure with three fixed-lengthof fields, one mandatory, two 4326 optional. 4328 struct T { 4329 uint16 a 4330 uint16 b (optional) 4331 uint16 c (optional) 4332 } 4334 This example is identical to Example 1, as illustrated below. 4336 (a) Describing all fields using SPARSEDATA 4338 Path-Data TLV 4339 Path to an instance of S ... 4340 SPARSEDATA TLV 4341 ComponentIDof(a), lengthof(a), valueof(a) 4342 ComponentIDof(b), lengthof(b), valueof(b) 4343 ComponentIDof(c), lengthof(c), valueof(c) 4345 (b) Describing a subset of fields using SPARSEDATA 4347 Path-Data TLV 4348 Path to an instance of S ... 4349 SPARSEDATA TLV 4350 ComponentIDof(a), lengthof(a), valueof(a) 4351 ComponentIDof(c), lengthof(c), valueof(c) 4353 (c) Describing all fields using a FULLDATA TLV 4355 Path-Data TLV 4356 Path to an instance of S ... 4357 FULLDATA TLV 4358 valueof(a) 4359 valueof(b) 4360 valueof(c) 4362 Note: FULLDATA TLV _cannot_ be used unless all fields are being 4363 described. 4365 ========== 4366 Example 3: 4367 ========== 4368 Structure with a mix of fixed-lengthof and variable-lengthof fields, 4369 some mandatory, some optional. Note in this case, b is variable 4370 sized 4372 struct U { 4373 uint16 a 4374 string b (optional) 4375 uint16 c (optional) 4376 } 4378 (a) Describing all fields using SPARSEDATA 4380 Path to an instance of U ... 4381 SPARSEDATA TLV 4382 ComponentIDof(a), lengthof(a), valueof(a) 4383 ComponentIDof(b), lengthof(b), valueof(b) 4384 ComponentIDof(c), lengthof(c), valueof(c) 4386 (b) Describing a subset of fields using SPARSEDATA 4388 Path to an instance of U ... 4389 SPARSEDATA TLV 4390 ComponentIDof(a), lengthof(a), valueof(a) 4391 ComponentIDof(c), lengthof(c), valueof(c) 4393 (c) Describing all fields using FULLDATA TLV 4395 Path to an instance of U ... 4396 FULLDATA TLV 4397 valueof(a) 4398 FULLDATA TLV 4399 valueof(b) 4400 valueof(c) 4402 Note: The variable-length field requires the addition of a FULLDATA 4403 TLV within the outer FULLDATA TLV as in the case of component b 4404 above. 4406 ========== 4407 Example 4: 4408 ========== 4410 Structure containing an array of another structure type. 4412 struct V { 4413 uint32 x 4414 uint32 y 4415 struct U z[] 4416 } 4418 (a) Encoding using SPARSEDATA, with two instances of z[], also 4419 described with SPARSEDATA, assuming only the 10th and 15th subscript 4420 of z[] are encoded. 4422 path to instance of V ... 4423 SPARSEDATA TLV 4424 ComponentIDof(x), lengthof(x), valueof(x) 4425 ComponentIDof(y), lengthof(y), valueof(y) 4426 ComponentIDof(z), lengthof(all below) 4427 ComponentID = 10 (i.e index 10 from z[]), lengthof(all below) 4428 ComponentIDof(a), lengthof(a), valueof(a) 4429 ComponentIDof(b), lengthof(b), valueof(b) 4430 ComponentID = 15 (index 15 from z[]), lengthof(all below) 4431 ComponentIDof(a), lengthof(a), valueof(a) 4432 ComponentIDof(c), lengthof(c), valueof(c) 4434 Note the holes in the components of z (10 followed by 15). Also note 4435 the gap in index 15 with only components a and c appearing but not b. 4437 Appendix D. Use Cases 4439 Assume LFB with following components for the following use cases. 4441 foo1, type u32, ID = 1 4443 foo2, type u32, ID = 2 4445 table1: type array, ID = 3 4446 components are: 4447 t1, type u32, ID = 1 4448 t2, type u32, ID = 2 // index into table 2 4449 KEY: nhkey, ID = 1, V = t2 4451 table2: type array, ID = 4 4452 components are: 4453 j1, type u32, ID = 1 4454 j2, type u32, ID = 2 4455 KEY: akey, ID = 1, V = { j1,j2 } 4457 table3: type array, ID = 5 4458 components are: 4459 someid, type u32, ID = 1 4460 name, type string variable sized, ID = 2 4462 table4: type array, ID = 6 4463 components are: 4464 j1, type u32, ID = 1 4465 j2, type u32, ID = 2 4466 j3, type u32, ID = 3 4467 j4, type u32, ID = 4 4468 KEY: mykey, ID = 1, V = { j1} 4470 table5: type array, ID = 7 4471 components are: 4472 p1, type u32, ID = 1 4473 p2, type array, ID = 2, array components of type-X 4475 Type-X: 4476 x1, ID 1, type u32 4477 x2, ID2 , type u32 4478 KEY: tkey, ID = 1, V = { x1} 4480 All examples will use valueof(x) to indicate the value of the 4481 referenced component x. In the case where F_SEL** are missing (bits 4482 equal to 00) then the flags will not show any selection. 4484 All the examples only show use of FULLDATA for data encoding; 4485 although SPARSEDATA would make more sense in certain occasions, the 4486 emphasis is on showing the message layout. Refer to Appendix C for 4487 examples that show usage of both FULLDATA and SPARSEDATA. 4489 1. To get foo1 4491 OPER = GET-TLV 4492 Path-data TLV: IDCount = 1, IDs = 1 4493 Result: 4494 OPER = GET-RESPONSE-TLV 4495 Path-data-TLV: 4496 flags=0, IDCount = 1, IDs = 1 4497 FULLDATA-TLV L = 4+4, V = valueof(foo1) 4499 2. To set foo2 to 10 4501 OPER = SET-TLV 4502 Path-data-TLV: 4503 flags = 0, IDCount = 1, IDs = 2 4504 FULLDATA TLV: L = 4+4, V=10 4506 Result: 4507 OPER = SET-RESPONSE-TLV 4508 Path-data-TLV: 4509 flags = 0, IDCount = 1, IDs = 2 4510 RESULT-TLV 4512 3. To dump table2 4514 OPER = GET-TLV 4515 Path-data-TLV: 4516 IDCount = 1, IDs = 4 4517 Result: 4518 OPER = GET-RESPONSE-TLV 4519 Path-data-TLV: 4520 flags = 0, IDCount = 1, IDs = 4 4521 FULLDATA=TLV: L = XXX, V= 4522 a series of: index, valueof(j1), valueof(j2) 4523 representing the entire table 4525 Note: One should be able to take a GET-RESPONSE-TLV and 4526 convert it to a SET-TLV. If the result in the above example 4527 is sent back in a SET-TLV, (instead of a GET-RESPONSE_TLV) 4528 then the entire contents of the table will be replaced at 4529 that point. 4531 4. Multiple operations Example. To create entry 0-5 of table2 4532 (Error conditions are ignored) 4534 OPER = SET-TLV 4535 Path-data-TLV: 4536 flags = 0 , IDCount = 1, IDs=4 4537 PATH-DATA-TLV 4538 flags = 0, IDCount = 1, IDs = 0 4539 FULLDATA-TLV valueof(j1), valueof(j2) of entry 0 4540 PATH-DATA-TLV 4541 flags = 0, IDCount = 1, IDs = 1 4542 FULLDATA-TLV valueof(j1), valueof(j2) of entry 1 4543 PATH-DATA-TLV 4544 flags = 0, IDCount = 1, IDs = 2 4545 FULLDATA-TLV valueof(j1), valueof(j2) of entry 2 4546 PATH-DATA-TLV 4547 flags = 0, IDCount = 1, IDs = 3 4548 FULLDATA-TLV valueof(j1), valueof(j2) of entry 3 4549 PATH-DATA-TLV 4550 flags = 0, IDCount = 1, IDs = 4 4551 FULLDATA-TLV valueof(j1), valueof(j2) of entry 4 4552 PATH-DATA-TLV 4553 flags = 0, IDCount = 1, IDs = 5 4554 FULLDATA-TLV valueof(j1), valueof(j2) of entry 5 4556 Result: 4557 OPER = SET-RESPONSE-TLV 4558 Path-data-TLV: 4559 flags = 0 , IDCount = 1, IDs=4 4560 PATH-DATA-TLV 4561 flags = 0, IDCount = 1, IDs = 0 4562 RESULT-TLV 4563 PATH-DATA-TLV 4564 flags = 0, IDCount = 1, IDs = 1 4565 RESULT-TLV 4566 PATH-DATA-TLV 4567 flags = 0, IDCount = 1, IDs = 2 4568 RESULT-TLV 4569 PATH-DATA-TLV 4570 flags = 0, IDCount = 1, IDs = 3 4571 RESULT-TLV 4572 PATH-DATA-TLV 4573 flags = 0, IDCount = 1, IDs = 4 4574 RESULT-TLV 4575 PATH-DATA-TLV 4576 flags = 0, IDCount = 1, IDs = 5 4577 RESULT-TLV 4579 5. Block operations (with holes) example. Replace entry 0,2 of 4580 table2 4582 OPER = SET-TLV 4583 Path-data TLV: 4584 flags = 0 , IDCount = 1, IDs=4 4585 PATH-DATA-TLV 4586 flags = 0, IDCount = 1, IDs = 0 4587 FULLDATA-TLV containing valueof(j1), valueof(j2) of 0 4588 PATH-DATA-TLV 4589 flags = 0, IDCount = 1, IDs = 2 4590 FULLDATA-TLV containing valueof(j1), valueof(j2) of 2 4592 Result: 4593 OPER = SET-TLV 4594 Path-data TLV: 4595 flags = 0 , IDCount = 1, IDs=4 4596 PATH-DATA-TLV 4597 flags = 0, IDCount = 1, IDs = 0 4598 RESULT-TLV 4599 PATH-DATA-TLV 4600 flags = 0, IDCount = 1, IDs = 2 4601 RESULT-TLV 4603 6. Getting rows example. Get first entry of table2. 4605 OPER = GET-TLV 4606 Path-data TLV: 4607 IDCount = 2, IDs=4.0 4609 Result: 4610 OPER = GET-RESPONSE-TLV 4611 Path-data TLV: 4612 IDCount = 2, IDs=4.0 4613 FULLDATA-TLV containing valueof(j1), valueof(j2) 4615 7. Get entry 0-5 of table2. 4617 OPER = GET-TLV 4618 Path-data-TLV: 4619 flags = 0, IDCount = 1, IDs=4 4620 PATH-DATA-TLV 4621 flags = 0, IDCount = 1, IDs = 0 4622 PATH-DATA-TLV 4623 flags = 0, IDCount = 1, IDs = 1 4624 PATH-DATA-TLV 4625 flags = 0, IDCount = 1, IDs = 2 4626 PATH-DATA-TLV 4627 flags = 0, IDCount = 1, IDs = 3 4628 PATH-DATA-TLV 4629 flags = 0, IDCount = 1, IDs = 4 4630 PATH-DATA-TLV 4631 flags = 0, IDCount = 1, IDs = 5 4633 Result: 4634 OPER = GET-RESPONSE-TLV 4635 Path-data-TLV: 4636 flags = 0, IDCount = 1, IDs=4 4637 PATH-DATA-TLV 4638 flags = 0, IDCount = 1, IDs = 0 4639 FULLDATA-TLV containing valueof(j1), valueof(j2) 4640 PATH-DATA-TLV 4641 flags = 0, IDCount = 1, IDs = 1 4642 FULLDATA-TLV containing valueof(j1), valueof(j2) 4643 PATH-DATA-TLV 4644 flags = 0, IDCount = 1, IDs = 2 4645 FULLDATA-TLV containing valueof(j1), valueof(j2) 4646 PATH-DATA-TLV 4647 flags = 0, IDCount = 1, IDs = 3 4648 FULLDATA-TLV containing valueof(j1), valueof(j2) 4649 PATH-DATA-TLV 4650 flags = 0, IDCount = 1, IDs = 4 4651 FULLDATA-TLV containing valueof(j1), valueof(j2) 4652 PATH-DATA-TLV 4653 flags = 0, IDCount = 1, IDs = 5 4654 FULLDATA-TLV containing valueof(j1), valueof(j2) 4656 8. Create a row in table2, index 5. 4658 OPER = SET-TLV 4659 Path-data-TLV: 4660 flags = 0, IDCount = 2, IDs=4.5 4661 FULLDATA-TLV containing valueof(j1), valueof(j2) 4663 Result: 4664 OPER = SET-RESPONSE-TLV 4665 Path-data TLV: 4666 flags = 0, IDCount = 1, IDs=4.5 4667 RESULT-TLV 4669 9. Dump contents of table1. 4671 OPER = GET-TLV 4672 Path-data TLV: 4673 flags = 0, IDCount = 1, IDs=3 4675 Result: 4676 OPER = GET-RESPONSE-TLV 4677 Path-data TLV 4678 flags = 0, IDCount = 1, IDs=3 4679 FULLDATA TLV, Length = XXXX 4680 (depending on size of table1) 4681 index, valueof(t1),valueof(t2) 4682 index, valueof(t1),valueof(t2) 4683 . 4684 . 4685 . 4687 10. Using Keys. Get row entry from table4 where j1=100. Recall, j1 4688 is a defined key for this table and its KeyID is 1. 4690 OPER = GET-TLV 4691 Path-data-TLV: 4692 flags = F_SELKEY IDCount = 1, IDs=6 4693 KEYINFO-TLV = KeyID=1, KEY_DATA=100 4695 Result: 4696 If j1=100 was at index 10 4697 OPER = GET-RESPONSE-TLV 4698 Path-data TLV: 4699 flags = 0, IDCount = 1, IDs=6.10 4700 FULLDATA-TLV containing 4701 valueof(j1), valueof(j2),valueof(j3),valueof(j4) 4703 11. Delete row with KEY match (j1=100, j2=200) in table 2. Note 4704 that the j1,j2 pair are a defined key for the table 2. 4706 OPER = DEL-TLV 4707 Path-data TLV: 4708 flags = F_SELKEY IDCount = 1, IDs=4 4709 KEYINFO TLV: {KeyID =1 KEY_DATA=100,200} 4711 Result: 4712 If (j1=100, j2=200) was at entry 15: 4713 OPER = DELETE-RESPONSE-TLV 4714 Path-data TLV: 4715 flags = 0 IDCount = 2, IDs=4.15 4716 RESULT-TLV 4718 12. Dump contents of table3. It should be noted that this table has 4719 a column with component name that is variable sized. The 4720 purpose of this use case is to show how such an component is to 4721 be encoded. 4723 OPER = GET-TLV 4724 Path-data-TLV: 4725 flags = 0 IDCount = 1, IDs=5 4727 Result: 4728 OPER = GET-RESPONSE-TLV 4729 Path-data TLV: 4730 flags = 0 IDCount = 1, IDs=5 4731 FULLDATA TLV, Length = XXXX 4732 index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), 4733 V = valueof(v) 4734 index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), 4735 V = valueof(v) 4736 index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), 4737 V = valueof(v) 4738 index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), 4739 V = valueof(v) 4740 . 4741 . 4742 . 4744 13. Multiple atomic operations. 4746 Note 1: This emulates adding a new nexthop entry and then 4747 atomically updating the L3 entries pointing to an old NH to 4748 point to a new one. The assumption is both tables are in the 4749 same LFB 4751 Note2: Observe the two operations on the LFB instance, both 4752 are SET operations. 4754 //Operation 1: Add a new entry to table2 index #20. 4755 OPER = SET-TLV 4756 Path-TLV: 4757 flags = 0, IDCount = 2, IDs=4.20 4758 FULLDATA TLV, V= valueof(j1),valueof(j2) 4760 // Operation 2: Update table1 entry which 4761 // was pointing with t2 = 10 to now point to 20 4762 OPER = SET-TLV 4763 Path-data-TLV: 4764 flags = F_SELKEY, IDCount = 1, IDs=3 4765 KEYINFO = KeyID=1 KEY_DATA=10 4766 Path-data-TLV 4767 flags = 0 IDCount = 1, IDs=2 4768 FULLDATA TLV, V= 20 4770 Result: 4771 //first operation, SET 4772 OPER = SET-RESPONSE-TLV 4773 Path-data-TLV 4774 flags = 0 IDCount = 3, IDs=4.20 4775 RESULT-TLV code = success 4776 FULLDATA TLV, V = valueof(j1),valueof(j2) 4777 // second operation SET - assuming entry 16 was updated 4778 OPER = SET-RESPONSE-TLV 4779 Path-data TLV 4780 flags = 0 IDCount = 2, IDs=3.16 4781 Path-Data TLV 4782 flags = 0 IDCount = 1, IDs = 2 4783 SET-RESULT-TLV code = success 4784 FULLDATA TLV, Length = XXXX v=20 4786 14. Selective setting. On table 4 -- for indices 1, 3, 5, 7, and 9. 4787 Replace j1 to 100, j2 to 200, j3 to 300. Leave j4 as is. 4789 PER = SET-TLV 4790 Path-data TLV 4791 flags = 0, IDCount = 1, IDs = 6 4792 Path-data TLV 4793 flags = 0, IDCount = 1, IDs = 1 4794 Path-data TLV 4795 flags = 0, IDCount = 1, IDs = 1 4796 FULLDATA TLV, Length = XXXX, V = {100} 4797 Path-data TLV 4798 flags = 0, IDCount = 1, IDs = 2 4799 FULLDATA TLV, Length = XXXX, V = {200} 4800 Path-data TLV 4801 flags = 0, IDCount = 1, IDs = 3 4802 FULLDATA TLV, Length = XXXX, V = {300} 4803 Path-data TLV 4804 flags = 0, IDCount = 1, IDs = 3 4805 Path-data TLV 4806 flags = 0, IDCount = 1, IDs = 1 4807 FULLDATA TLV, Length = XXXX, V = {100} 4808 Path-data TLV 4809 flags = 0, IDCount = 1, IDs = 2 4810 FULLDATA TLV, Length = XXXX, V = {200} 4811 Path-data TLV 4812 flags = 0, IDCount = 1, IDs = 3 4813 FULLDATA TLV, Length = XXXX, V = {300} 4814 Path-data TLV 4815 flags = 0, IDCount = 1, IDs = 5 4816 Path-data TLV 4817 flags = 0, IDCount = 1, IDs = 1 4818 FULLDATA TLV, Length = XXXX, V = {100} 4819 Path-data TLV 4820 flags = 0, IDCount = 1, IDs = 2 4821 FULLDATA TLV, Length = XXXX, V = {200} 4822 Path-data TLV 4823 flags = 0, IDCount = 1, IDs = 3 4824 FULLDATA TLV, Length = XXXX, V = {300} 4825 Path-data TLV 4826 flags = 0, IDCount = 1, IDs = 7 4827 Path-data TLV 4828 flags = 0, IDCount = 1, IDs = 1 4829 FULLDATA TLV, Length = XXXX, V = {100} 4830 Path-data TLV 4831 flags = 0, IDCount = 1, IDs = 2 4832 FULLDATA TLV, Length = XXXX, V = {200} 4833 Path-data TLV 4834 flags = 0, IDCount = 1, IDs = 3 4835 FULLDATA TLV, Length = XXXX, V = {300} 4836 Path-data TLV 4837 flags = 0, IDCount = 1, IDs = 9 4838 Path-data TLV 4839 flags = 0, IDCount = 1, IDs = 1 4840 FULLDATA TLV, Length = XXXX, V = {100} 4841 Path-data TLV 4842 flags = 0, IDCount = 1, IDs = 2 4843 FULLDATA TLV, Length = XXXX, V = {200} 4844 Path-data TLV 4845 flags = 0, IDCount = 1, IDs = 3 4846 FULLDATA TLV, Length = XXXX, V = {300} 4848 response: 4850 OPER = SET-RESPONSE-TLV 4851 Path-data TLV 4852 flags = 0, IDCount = 1, IDs = 6 4853 Path-data TLV 4854 flags = 0, IDCount = 1, IDs = 1 4855 Path-data TLV 4856 flags = 0, IDCount = 1, IDs = 1 4857 RESULT-TLV 4858 Path-data TLV 4859 flags = 0, IDCount = 1, IDs = 2 4860 RESULT-TLV 4861 Path-data TLV 4862 flags = 0, IDCount = 1, IDs = 3 4863 RESULT-TLV 4864 Path-data TLV 4865 flags = 0, IDCount = 1, IDs = 3 4866 Path-data TLV 4867 flags = 0, IDCount = 1, IDs = 1 4868 RESULT-TLV 4869 Path-data TLV 4870 flags = 0, IDCount = 1, IDs = 2 4871 RESULT-TLV 4872 Path-data TLV 4873 flags = 0, IDCount = 1, IDs = 3 4874 RESULT-TLV 4875 Path-data TLV 4876 flags = 0, IDCount = 1, IDs = 5 4877 Path-data TLV 4878 flags = 0, IDCount = 1, IDs = 1 4879 RESULT-TLV 4880 Path-data TLV 4881 flags = 0, IDCount = 1, IDs = 2 4882 RESULT-TLV 4883 Path-data TLV 4884 flags = 0, IDCount = 1, IDs = 3 4885 RESULT-TLV 4886 Path-data TLV 4887 flags = 0, IDCount = 1, IDs = 7 4888 Path-data TLV 4889 flags = 0, IDCount = 1, IDs = 1 4890 RESULT-TLV 4891 Path-data TLV 4892 flags = 0, IDCount = 1, IDs = 2 4893 RESULT-TLV 4894 Path-data TLV 4895 flags = 0, IDCount = 1, IDs = 3 4896 RESULT-TLV 4897 Path-data TLV 4898 flags = 0, IDCount = 1, IDs = 9 4899 Path-data TLV 4900 flags = 0, IDCount = 1, IDs = 1 4901 RESULT-TLV 4902 Path-data TLV 4903 flags = 0, IDCount = 1, IDs = 2 4904 RESULT-TLV 4905 Path-data TLV 4906 flags = 0, IDCount = 1, IDs = 3 4907 RESULT-TLV 4909 15. Manipulation of table of table examples. Get x1 from table10 4910 row with index 4, inside table5 entry 10 4912 operation = GET-TLV 4913 Path-data-TLV 4914 flags = 0 IDCount = 5, IDs=7.10.2.4.1 4916 Results: 4917 operation = GET-RESPONSE-TLV 4918 Path-data-TLV 4919 flags = 0 IDCount = 5, IDs=7.10.2.4.1 4920 FULLDATA TLV: L=XXXX, V = valueof(x1) 4922 16. From table5's row 10 table10, get X2s based on on the value of 4923 x1 equaling 10 (recall x1 is KeyID 1) 4925 operation = GET-TLV 4926 Path-data-TLV 4927 flag = F_SELKEY, IDCount=3, IDS = 7.10.2 4928 KEYINFO TLV, KeyID = 1, KEYDATA = 10 4929 Path-data TLV 4930 IDCount = 1, IDS = 2 //select x2 4932 Results: 4933 If x1=10 was at entry 11: 4934 operation = GET-RESPONSE-TLV 4935 Path-data-TLV 4936 flag = 0, IDCount=5, IDS = 7.10.2.11 4937 Path-data TLV 4938 flags = 0 IDCount = 1, IDS = 2 4939 FULLDATA TLV: L=XXXX, V = valueof(x2) 4941 17. Further example of manipulating a table of tables 4943 Consider table 6 which is defined as: 4944 table6: type array, ID = 8 4945 components are: 4946 p1, type u32, ID = 1 4947 p2, type array, ID = 2, array components of type type-A 4949 type-A: 4950 a1, type u32, ID 1, 4951 a2, type array ID2 ,array components of type type-B 4953 type-B: 4954 b1, type u32, ID 1 4955 b2, type u32, ID 2 4957 If for example one wanted to set by replacing: 4958 table6.10.p1 to 111 4959 table6.10.p2.20.a1 to 222 4960 table6.10.p2.20.a2.30.b1 to 333 4962 in one message and one operation. 4964 There are two ways to do this: 4965 a) using nesting 4966 b) using a flat path data 4968 A. Method using nesting 4969 in one message with a single operation 4971 operation = SET-TLV 4972 Path-data-TLV 4973 flags = 0 IDCount = 2, IDs=6.10 4974 Path-data-TLV 4975 flags = 0, IDCount = 1, IDs=1 4976 FULLDATA TLV: L=XXXX, 4977 V = {111} 4978 Path-data-TLV 4979 flags = 0 IDCount = 2, IDs=2.20 4980 Path-data-TLV 4981 flags = 0, IDCount = 1, IDs=1 4982 FULLDATA TLV: L=XXXX, 4983 V = {222} 4984 Path-data TLV : 4985 flags = 0, IDCount = 3, IDs=2.30.1 4986 FULLDATA TLV: L=XXXX, 4987 V = {333} 4988 Result: 4989 operation = SET-RESPONSE-TLV 4990 Path-data-TLV 4991 flags = 0 IDCount = 2, IDs=6.10 4992 Path-data-TLV 4993 flags = 0, IDCount = 1, IDs=1 4994 RESULT-TLV 4995 Path-data-TLV 4996 flags = 0 IDCount = 2, IDs=2.20 4997 Path-data-TLV 4998 flags = 0, IDCount = 1, IDs=1 4999 RESULT-TLV 5000 Path-data TLV : 5001 flags = 0, IDCount = 3, IDs=2.30.1 5002 RESULT-TLV 5004 B. Method using a flat path data in 5005 one message with a single operation 5007 operation = SET-TLV 5008 Path-data TLV : 5009 flags = 0, IDCount = 3, IDs=6.10.1 5010 FULLDATA TLV: L=XXXX, 5011 V = {111} 5012 Path-data TLV : 5013 flags = 0, IDCount = 5, IDs=6.10.1.20.1 5014 FULLDATA TLV: L=XXXX, 5015 V = {222} 5016 Path-data TLV : 5017 flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1 5018 FULLDATA TLV: L=XXXX, 5019 V = {333} 5020 Result: 5021 operation = SET-TLV 5022 Path-data TLV : 5023 flags = 0, IDCount = 3, IDs=6.10.1 5024 RESULT-TLV 5025 Path-data TLV : 5026 flags = 0, IDCount = 5, IDs=6.10.1.20.1 5027 RESULT-TLV 5028 Path-data TLV : 5029 flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1 5030 RESULT-TLV 5032 18. Get a whole LFB (all its components, etc.). 5034 For example: at startup a CE might well want the entire FE 5035 OBJECT LFB. So, in a request targeted at class 1, instance 5036 1, one might find: 5038 operation = GET-TLV 5039 Path-data-TLV 5040 flags = 0 IDCount = 0 5042 result: 5043 operation = GET-RESPONSE-TLV 5044 Path-data-TLV 5045 flags = 0 IDCount = 0 5046 FULLDATA encoding of the FE Object LFB 5048 Authors' Addresses 5050 Ligang Dong 5051 Zhejiang Gongshang University 5052 149 Jiaogong Road 5053 Hangzhou 310035 5054 P.R.China 5056 Phone: +86-571-88071024 5057 Email: donglg@mail.zjgsu.edu.cn 5059 Avri Doria 5060 Lulea University of Technology 5061 Rainbow Way 5062 Lulea SE-971 87 5063 Sweden 5065 Phone: +46 73 277 1788 5066 Email: avri@ltu.se 5068 Ram Gopal 5069 Nokia 5070 5, Wayside Road 5071 Burlington, MA 310035 5072 USA 5074 Phone: +1-781-993-3685 5075 Email: ram.gopal@nokia.com 5077 Robert Haas 5078 IBM 5079 Saumerstrasse 4 5080 8803 Ruschlikon 5081 Switzerland 5083 Phone: 5084 Email: rha@zurich.ibm.com 5085 Jamal Hadi Salim 5086 Znyx 5087 Ottawa, Ontario 5088 Canada 5090 Phone: 5091 Email: hadi@znyx.com 5093 Hormuzd M Khosravi 5094 Intel 5095 2111 NE 25th Avenue 5096 Hillsboro, OR 97124 5097 USA 5099 Phone: +1 503 264 0334 5100 Email: hormuzd.m.khosravi@intel.com 5102 Weiming Wang 5103 Zhejiang Gongshang University 5104 149 Jiaogong Road 5105 Hangzhou 310035 5106 P.R.China 5108 Phone: +86-571-88057712 5109 Email: wmwang@mail.zjgsu.edu.cn 5111 Full Copyright Statement 5113 Copyright (C) The IETF Trust (2007). 5115 This document is subject to the rights, licenses and restrictions 5116 contained in BCP 78, and except as set forth therein, the authors 5117 retain all their rights. 5119 This document and the information contained herein are provided on an 5120 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 5121 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 5122 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 5123 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 5124 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 5125 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 5127 Intellectual Property 5129 The IETF takes no position regarding the validity or scope of any 5130 Intellectual Property Rights or other rights that might be claimed to 5131 pertain to the implementation or use of the technology described in 5132 this document or the extent to which any license under such rights 5133 might or might not be available; nor does it represent that it has 5134 made any independent effort to identify any such rights. Information 5135 on the procedures with respect to rights in RFC documents can be 5136 found in BCP 78 and BCP 79. 5138 Copies of IPR disclosures made to the IETF Secretariat and any 5139 assurances of licenses to be made available, or the result of an 5140 attempt made to obtain a general license or permission for the use of 5141 such proprietary rights by implementers or users of this 5142 specification can be obtained from the IETF on-line IPR repository at 5143 http://www.ietf.org/ipr. 5145 The IETF invites any interested party to bring to its attention any 5146 copyrights, patents or patent applications, or other proprietary 5147 rights that may cover technology that may be required to implement 5148 this standard. Please address the information to the IETF at 5149 ietf-ipr@ietf.org. 5151 Acknowledgment 5153 Funding for the RFC Editor function is provided by the IETF 5154 Administrative Support Activity (IASA).