idnits 2.17.1 draft-ietf-forces-protocol-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 5109. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 5120. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 5127. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 5133. 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 to send any response message back to this message sender. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2007) is 6252 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 1757, but not defined == Missing Reference: 'SELECTOR' is mentioned on line 1758, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'FE-MODEL' ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 3654 ** Downref: Normative reference to an Informational RFC: RFC 3746 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 5 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 ETRI 4 Intended status: Standards Track R. Haas (Ed.) 5 Expires: August 5, 2007 IBM 6 J. Hadi Salim (Ed.) 7 Znyx 8 H. Khosravi (Ed.) 9 Intel 10 W. M. Wang (Ed.) 11 Zhejiang Gongshang University 12 March 2007 14 ForCES Protocol Specification 15 draft-ietf-forces-protocol-09.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on August 5, 2007. 42 Copyright Notice 44 Copyright (C) The IETF Trust (2007). 46 Abstract 48 This document specifies the Forwarding and Control Element Separation 49 (ForCES) protocol. ForCES protocol is used for communications 50 between Control Elements(CEs) and Forwarding Elements (FEs) in a 51 ForCES Network Element (ForCES NE). This specification is intended 52 to meet the ForCES protocol requirements defined in RFC3654. Besides 53 the ForCES protocol messages, the specification also defines the 54 framework, the mechanisms, and the Transport Mapping Layer (TML) 55 requirements for ForCES protocol. 57 Authors 59 The participants in the ForCES Protocol Team, primary co-authors and 60 co-editors, of this protocol specification, are: 62 Ligang Dong (Zhejiang Gongshang University), Avri Doria (Lulea 63 University of Technology), Ram Gopal (Nokia), Robert Haas (IBM), 64 Jamal Hadi Salim (Znyx), Hormuzd M Khosravi (Intel), and Weiming Wang 65 (Zhejiang Gongshang University). 67 Table of Contents 69 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 6 70 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 71 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9 72 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 12 73 4.1. Protocol Framework . . . . . . . . . . . . . . . . . . . 12 74 4.1.1. The PL . . . . . . . . . . . . . . . . . . . . . . . 14 75 4.1.2. The TML . . . . . . . . . . . . . . . . . . . . . . . 15 76 4.1.3. The FEM/CEM Interface . . . . . . . . . . . . . . . . 15 77 4.2. ForCES Protocol Phases . . . . . . . . . . . . . . . . . 16 78 4.2.1. Pre-association . . . . . . . . . . . . . . . . . . . 17 79 4.2.2. Post-association . . . . . . . . . . . . . . . . . . 18 80 4.3. Protocol Mechanisms . . . . . . . . . . . . . . . . . . . 20 81 4.3.1. Transactions, Atomicity, Execution and Responses . . 20 82 4.3.2. Scalability . . . . . . . . . . . . . . . . . . . . . 24 83 4.3.3. Heartbeat Mechanism . . . . . . . . . . . . . . . . . 25 84 4.3.4. FE Object and FE Protocol LFBs . . . . . . . . . . . 25 85 4.4. Protocol Scenarios . . . . . . . . . . . . . . . . . . . 25 86 4.4.1. Association Setup State . . . . . . . . . . . . . . . 26 87 4.4.2. Association Established state or Steady State . . . . 27 88 4.4.3. Transaction messaging . . . . . . . . . . . . . . . . 29 89 5. TML Requirements . . . . . . . . . . . . . . . . . . . . . . 31 90 5.1. TML Parameterization . . . . . . . . . . . . . . . . . . 32 91 6. Message Encapsulation . . . . . . . . . . . . . . . . . . . . 33 92 6.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 33 93 6.2. Type Length Value (TLV) Structuring . . . . . . . . . . . 38 94 6.2.1. Nested TLVs . . . . . . . . . . . . . . . . . . . . . 39 95 6.2.2. Scope of the T in TLV . . . . . . . . . . . . . . . . 39 96 6.3. ILV . . . . . . . . . . . . . . . . . . . . . . . . . . . 39 97 6.4. Important Protocol encapsulations . . . . . . . . . . . . 40 98 6.4.1. Paths . . . . . . . . . . . . . . . . . . . . . . . . 40 99 6.4.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . 41 100 6.4.3. DATA TLVs . . . . . . . . . . . . . . . . . . . . . . 41 101 6.4.4. Addressing LFB entities . . . . . . . . . . . . . . . 41 102 7. Protocol Construction . . . . . . . . . . . . . . . . . . . . 43 103 7.1. Protocol Grammar . . . . . . . . . . . . . . . . . . . . 43 104 7.1.1. Protocol BNF . . . . . . . . . . . . . . . . . . . . 43 105 7.1.2. Protocol Encoding Visualization . . . . . . . . . . . 58 106 7.2. Core ForCES LFBs . . . . . . . . . . . . . . . . . . . . 61 107 7.2.1. FE Protocol LFB . . . . . . . . . . . . . . . . . . . 62 108 7.2.2. FE Object LFB . . . . . . . . . . . . . . . . . . . . 65 109 7.3. Semantics of Message Direction . . . . . . . . . . . . . 65 110 7.4. Association Messages . . . . . . . . . . . . . . . . . . 66 111 7.4.1. Association Setup Message . . . . . . . . . . . . . . 66 112 7.4.2. Association Setup Response Message . . . . . . . . . 68 113 7.4.3. Association Teardown Message . . . . . . . . . . . . 69 114 7.5. Configuration Messages . . . . . . . . . . . . . . . . . 70 115 7.5.1. Config Message . . . . . . . . . . . . . . . . . . . 70 116 7.5.2. Config Response Message . . . . . . . . . . . . . . . 72 117 7.6. Query Messages . . . . . . . . . . . . . . . . . . . . . 73 118 7.6.1. Query Message . . . . . . . . . . . . . . . . . . . . 74 119 7.6.2. Query Response Message . . . . . . . . . . . . . . . 75 120 7.7. Event Notification Message . . . . . . . . . . . . . . . 76 121 7.8. Packet Redirect Message . . . . . . . . . . . . . . . . . 78 122 7.9. Heartbeat Message . . . . . . . . . . . . . . . . . . . . 80 123 8. High Availability Support . . . . . . . . . . . . . . . . . . 82 124 8.1. Relation with the FE Protocol . . . . . . . . . . . . . . 82 125 8.2. Responsibilities for HA . . . . . . . . . . . . . . . . . 85 126 9. Security Considerations . . . . . . . . . . . . . . . . . . . 87 127 9.1. No Security . . . . . . . . . . . . . . . . . . . . . . . 87 128 9.1.1. Endpoint Authentication . . . . . . . . . . . . . . . 87 129 9.1.2. Message authentication . . . . . . . . . . . . . . . 88 130 9.2. ForCES PL and TML security service . . . . . . . . . . . 88 131 9.2.1. Endpoint authentication service . . . . . . . . . . . 88 132 9.2.2. Message authentication service . . . . . . . . . . . 88 133 9.2.3. Confidentiality service . . . . . . . . . . . . . . . 88 134 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 89 135 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 90 136 11.1. Normative References . . . . . . . . . . . . . . . . . . 90 137 11.2. Informational References . . . . . . . . . . . . . . . . 90 138 Appendix A. IANA Considerations . . . . . . . . . . . . . . . . 91 139 A.1. Message Type Name Space . . . . . . . . . . . . . . . . . 91 140 A.2. Operation Selection . . . . . . . . . . . . . . . . . . . 92 141 A.3. Header Flags . . . . . . . . . . . . . . . . . . . . . . 93 142 A.4. TLV Type Name Space . . . . . . . . . . . . . . . . . . . 93 143 A.5. Result-TLV Result Values . . . . . . . . . . . . . . . . 93 144 A.6. Association Setup Response . . . . . . . . . . . . . . . 94 145 A.7. Association Teardown Message . . . . . . . . . . . . . . 95 146 Appendix B. ForCES Protocol LFB schema . . . . . . . . . . . . . 96 147 B.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 101 148 B.2. Attributes . . . . . . . . . . . . . . . . . . . . . . . 102 149 Appendix C. Data Encoding Examples . . . . . . . . . . . . . . . 103 150 Appendix D. Use Cases . . . . . . . . . . . . . . . . . . . . . 107 151 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 123 152 Intellectual Property and Copyright Statements . . . . . . . . . 125 154 1. Terminology and Conventions 156 The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, 157 RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted 158 as described in BCP 14, RFC2119 [RFC2119]. 160 2. Introduction 162 Forwarding and Control Element Separation (ForCES) defines an 163 architectural framework and associated protocols to standardize 164 information exchange between the control plane and the forwarding 165 plane in a ForCES Network Element (ForCES NE). RFC 3654 has defined 166 the ForCES requirements, and RFC 3746 has defined the ForCES 167 framework. While there may be multiple protocols used within the 168 overall ForCES architecture, the term "ForCES protocol" and 169 "protocol" as used in this document refers to the protocol used to 170 standardize the information exchange between Control Elements (CEs) 171 and Forwarding Elements (FEs) only. 173 The ForCES FE model [FE-MODEL] presents a formal way to define FE 174 Logical Function Blocks (LFBs) using XML. LFB configuration 175 attributes, capabilities, and associated events are defined when the 176 LFB is formally created. The LFBs within the FE are accordingly 177 controlled in a standardized way by the ForCES protocol. 179 This document defines the ForCES protocol specifications. The ForCES 180 protocol works in a master-slave mode in which FEs are slaves and CEs 181 are masters. The protocol includes commands for transport of Logical 182 Function Block(LFB) configuration information, association setup, 183 status, and event notifications, etc. 185 This specification does not define a transport mechanism for protocol 186 messages. A discussion of service primitives that must be provided 187 by the underlying transport interface will be discussed in a future 188 document. 190 Section 3 provides a glossary of terminology used in the 191 specification. 193 Section 4 provides an overview of the protocol, including a 194 discussion on the protocol framework, descriptions of the Protocol 195 Layer (PL) and a Transport Mapping Layer (TML), as well as of the 196 ForCES protocol mechanisms. Section 4.4 describes several Protocol 197 scenarios and includes message exchange descriptions. 199 While this document does not define the TML, Section 5 details the 200 services that a TML must provide (TML requirements). 202 The ForCES protocol defines a common header for all protocol 203 messages. The header is defined in Section 6.1, while the protocol 204 messages are defined in Section 7. 206 Section 8 describes the protocol support for high availability 207 mechanisms including redundancy and fail over. 209 Section 9 defines the security mechanisms provided by the PL and TML. 211 3. Definitions 213 This document follows the terminology defined by the ForCES 214 Requirements in [RFC3654] and by the ForCES framework in [RFC3746]. 215 The definitions below are repeated below for clarity. 217 Addressable Entity (AE) - A physical device that is directly 218 addressable given some interconnect technology. For example, on IP 219 networks, it is a device which can be reached using an IP address; 220 and on a switch fabric, it is a device which can be reached using a 221 switch fabric port number. 223 Control Element (CE) - A logical entity that implements the ForCES 224 protocol and uses it to instruct one or more FEs on how to process 225 packets. CEs handle functionality such as the execution of control 226 and signaling protocols. 228 CE Manager (CEM) - A logical entity responsible for generic CE 229 management tasks. It is particularly used during the pre-association 230 phase to determine with which FE(s) a CE should communicate. This 231 process is called FE discovery and may involve the CE manager 232 learning the capabilities of available FEs. 234 Datapath - A conceptual path taken by packets within the forwarding 235 plane inside an FE. 237 Forwarding Element (FE) - A logical entity that implements the ForCES 238 protocol. FEs use the underlying hardware to provide per-packet 239 processing and handling as directed/controlled by one or more CEs via 240 the ForCES protocol. 242 FE Model - A model that describes the logical processing functions of 243 an FE. 245 FE Manager (FEM) - A logical entity responsible for generic FE 246 management tasks. It is used during pre-association phase to 247 determine with which CE(s) an FE should communicate. This process is 248 called CE discovery and may involve the FE manager learning the 249 capabilities of available CEs. An FE manager may use anything from a 250 static configuration to a pre-association phase protocol (see below) 251 to determine which CE(s) to use. Being a logical entity, an FE 252 manager might be physically combined with any of the other logical 253 entities such as FEs. 255 ForCES Network Element (NE) - An entity composed of one or more CEs 256 and one or more FEs. To entities outside an NE, the NE represents a 257 single point of management. Similarly, an NE usually hides its 258 internal organization from external entities. 260 High Touch Capability - This term will be used to apply to the 261 capabilities found in some forwarders to take action on the contents 262 or headers of a packet based on content other than what is found in 263 the IP header. Examples of these capabilities include NAT-PT, 264 firewall, and L7 content recognition. 266 Inter-FE Topology - See FE Topology. 268 Intra-FE Topology - See LFB Topology. 270 LFB (Logical Function Block) - The basic building block that is 271 operated on by the ForCES protocol. The LFB is a well defined, 272 logically separable functional block that resides in an FE and is 273 controlled by the CE via ForCES protocol. The LFB may reside at the 274 FE's datapath and process packets or may be purely an FE control or 275 configuration entity that is operated on by the CE. Note that the 276 LFB is a functionally accurate abstraction of the FE's processing 277 capabilities, but not a hardware-accurate representation of the FE 278 implementation. 280 FE Topology - A representation of how the multiple FEs within a 281 single NE are interconnected. Sometimes this is called inter-FE 282 topology, to be distinguished from intra-FE topology (i.e., LFB 283 topology). 285 LFB (Logical Function Block) and LFB Instance - LFBs are categorized 286 by LFB Classes. An LFB Instance represents an LFB Class (or Type) 287 existence. There may be multiple instances of the same LFB Class (or 288 Type) in an FE. An LFB Class is represented by an LFB Class ID, and 289 an LFB Instance is represented by an LFB Instance ID. As a result, 290 an LFB Class ID associated with an LFB Instance ID uniquely specifies 291 an LFB existence. 293 LFB Metadata - Metadata is used to communicate per-packet state from 294 one LFB to another, but is not sent across the network. The FE model 295 defines how such metadata is identified, produced and consumed by the 296 LFBs. It defines the functionality but not how metadata is encoded 297 within an implementation. 299 LFB Attribute - Operational parameters of the LFBs that must be 300 visible to the CEs are conceptualized in the FE model as the LFB 301 attributes. The LFB attributes include, for example, flags, single 302 parameter arguments, complex arguments, and tables that the CE can 303 read and/or write via the ForCES protocol (see below). 305 LFB Topology - Representation of how the LFB instances are logically 306 interconnected and placed along the datapath within one FE. 307 Sometimes it is also called intra-FE topology, to be distinguished 308 from inter-FE topology. 310 Pre-association Phase - The period of time during which an FE Manager 311 (see below) and a CE Manager (see below) are determining which FE(s) 312 and CE(s) should be part of the same network element. 314 Post-association Phase - The period of time during which an FE knows 315 which CE is to control it and vice versa. This includes the time 316 during which the CE and FE are establishing communication with one 317 another. 319 ForCES Protocol - While there may be multiple protocols used within 320 the overall ForCES architecture, the term "ForCES protocol" and 321 "protocol" refer to the Fp reference point in the ForCES Framework in 322 [RFC3746]. This protocol does not apply to CE-to-CE communication, 323 FE-to-FE communication, or to communication between FE and CE 324 managers. Basically, the ForCES protocol works in a master-slave 325 mode in which FEs are slaves and CEs are masters. This document 326 defines the specifications for this ForCES protocol. 328 ForCES Protocol Layer (ForCES PL) - A layer in ForCES protocol 329 architecture that defines the ForCES protocol messages, the protocol 330 state transfer scheme, as well as the ForCES protocol architecture 331 itself (including requirements of ForCES TML (see below). 332 Specifications of ForCES PL are defined by this document. 334 ForCES Protocol Transport Mapping Layer (ForCES TML) - A layer in 335 ForCES protocol architecture that uses the capabilities of existing 336 transport protocols to specifically address protocol message 337 transportation issues, such as how the protocol messages are mapped 338 to different transport media (like TCP, IP, ATM, Ethernet, etc), and 339 how to achieve and implement reliability, multicast, ordering, etc. 340 The ForCES TML specifications are detailed in separate ForCES 341 documents, one for each TML. 343 4. Overview 345 The reader is referred to the Framework document [RFC3746], and in 346 particular sections 3 and 4, for an architectural overview and an 347 explanation of how the ForCES protocol fits in. There may be some 348 content overlap between the framework document and this section in 349 order to provide clarity. This document is authoritative on the 350 protocol whereas [RFC3746] is authoritative on the architecture. 352 4.1. Protocol Framework 354 Figure 1 below is reproduced from the Framework document for clarity. 355 It shows a NE with two CEs and two FEs. 357 --------------------------------------- 358 | ForCES Network Element | 359 -------------- Fc | -------------- -------------- | 360 | CE Manager |---------+-| CE 1 |------| CE 2 | | 361 -------------- | | | Fr | | | 362 | | -------------- -------------- | 363 | Fl | | | Fp / | 364 | | Fp| |----------| / | 365 | | | |/ | 366 | | | | | 367 | | | Fp /|----| | 368 | | | /--------/ | | 369 -------------- Ff | -------------- -------------- | 370 | FE Manager |---------+-| FE 1 | Fi | FE 2 | | 371 -------------- | | |------| | | 372 | -------------- -------------- | 373 | | | | | | | | | | 374 ----+--+--+--+----------+--+--+--+----- 375 | | | | | | | | 376 | | | | | | | | 377 Fi/f Fi/f 379 Fp: CE-FE interface 380 Fi: FE-FE interface 381 Fr: CE-CE interface 382 Fc: Interface between the CE Manager and a CE 383 Ff: Interface between the FE Manager and an FE 384 Fl: Interface between the CE Manager and the FE Manager 385 Fi/f: FE external interface 387 Figure 1: ForCES Architectural Diagram 389 The ForCES protocol domain is found in the Fp Reference Point. The 390 Protocol Element configuration reference points, Fc and Ff also play 391 a role in the booting up of the ForCES Protocol. The protocol 392 element configuration (indicated by reference points Fc, Ff, and Fl 393 in [RFC3746] ) is out of scope of the ForCES protocol but is touched 394 on in this document in discussion of FEM and CEM since it is an 395 integral part of the protocol pre-association phase. 397 Figure 2 below shows further breakdown of the Fp interface by example 398 of an MPLS QoS enabled Network Element. 400 ------------------------------------------------- 401 | | | | | | | 402 |OSPF |RIP |BGP |RSVP |LDP |. . . | 403 | | | | | | | 404 ------------------------------------------------- CE 405 | ForCES Interface | 406 ------------------------------------------------- 407 ^ ^ 408 | | 409 ForCES | |data 410 control | |packets 411 messages| |(e.g., routing packets) 412 | | 413 v v 414 ------------------------------------------------- 415 | ForCES Interface | 416 ------------------------------------------------- FE 417 | | | | | | | 418 |LPM Fwd|Meter |Shaper |MPLS |Classi-|. . . | 419 | | | | |fier | | 420 ------------------------------------------------- 422 Figure 2: Examples of CE and FE functions 424 The ForCES Interface shown in Figure 2 constitutes two pieces: the PL 425 and the TML. 427 This is depicted in Figure 3 below. 429 +------------------------------------------------ 430 | CE PL | 431 +------------------------------------------------ 432 | CE TML | 433 +------------------------------------------------ 434 ^ 435 | 436 ForCES | (i.e ForCES data + control 437 PL | packets ) 438 messages | 439 over | 440 specific | 441 TML | 442 encaps | 443 and | 444 transport | 445 | 446 v 447 +------------------------------------------------ 448 | FE TML | 449 +------------------------------------------------ 450 | FE PL | 451 +------------------------------------------------ 453 Figure 3: ForCES Interface 455 The PL is in fact the ForCES protocol. Its semantics and message 456 layout are defined in this document. The TML Layer is necessary to 457 connect two ForCES PLs as shown in Figure 3 above. The TML is out of 458 scope for this document but is within scope of ForCES. This document 459 defines requirements the PL needs the TML to meet. 461 Both the PL and the TML are standardized by the IETF. While only one 462 PL is defined, different TMLs are expected to be standardized. To 463 interoperate the TML at the CE and FE are expected to conform to the 464 same definition. 466 On transmit, the PL delivers its messages to the TML. The local TML 467 delivers the message to the destination TML. On receive, the TML 468 delivers the message to its destination PL. 470 4.1.1. The PL 472 The PL is common to all implementations of ForCES and is standardized 473 by the IETF as defined in this document. The PL is responsible for 474 associating an FE or CE to an NE. It is also responsible for tearing 475 down such associations. An FE uses the PL to transmit various 476 subscribed-to events to the CE PL as well as to respond to various 477 status requests issued from the CE PL. The CE configures both the FE 478 and associated LFBs' operational parameters using the PL. In 479 addition the CE may send various requests to the FE to activate or 480 deactivate it, reconfigure its HA parameterization, subscribe to 481 specific events etc. More details can be found in Section 7. 483 4.1.2. The TML 485 The TML transports the PL messages. The TML is where the issues of 486 how to achieve transport level reliability, congestion control, 487 multicast, ordering, etc. are handled. It is expected that more than 488 one TML will be standardized. The various possible TMLs could vary 489 their implementations based on the capabilities of underlying media 490 and transport. However, since each TML is standardized, 491 interoperability is guaranteed as long as both endpoints support the 492 same TML. All ForCES Protocol Layer implementations MUST be portable 493 across all TMLs, because all TMLs MUST have the top edge semantics 494 defined in this document. 496 4.1.3. The FEM/CEM Interface 498 The FEM and CEM components, although valuable in the setup and 499 configurations of both the PL and TML, are out of scope of the ForCES 500 protocol. The best way to think of them is as configurations/ 501 parameterizations for the PL and TML before they become active (or 502 even at runtime based on implementation). In the simplest case, the 503 FE or CE reads a static configuration file. RFC 3746 has a more 504 detailed description on how the FEM and CEM could be used. The pre- 505 association phase, where the CEM and FEM can be used, are described 506 briefly in Section 4.2.1. 508 An example of typical things the FEM/CEM could configure would be TML 509 specific parameterizations such as: 511 a. How the TML connection should happen (for example what IP 512 addresses to use, transport modes etc); 514 b. The ID for the FE or CE (which would also be issued during the 515 pre-association phase). 517 c. Security parameterization such as keys etc. 519 d. Connection association parameters 521 Example of connection association parameters this might be: 523 o simple parameters: send up to 3 association messages every 1 524 second 526 o complex parameters: send up to 4 association messages with 527 increasing exponential timeout 529 4.2. ForCES Protocol Phases 531 ForCES, in relation to NEs, involves two phases: the Pre-Association 532 phase, where configuration/initialization/bootup of the TML and PL 533 layer happens, and the association phase where the ForCES protocol 534 operates to manipulate the parameters of the FEs. 536 FE assoiated CE configures transition to UP 537 +---->--->---+ +--->---->---->---->------->----+ 538 | | | Y 539 ^ Y | | 540 | | | Y 541 +---+-------+ +------+--+ +--------+ 542 |FE Pre- | | FE | | FE | 543 |Association| | DOWN | CE configures DOWN | UP | 544 |Phase | | State +<------<-----<------<-- + State | 545 | | | | | | 546 +-----------+ +---------+ +--------+ 547 ^ Y 548 | | 549 +-<---<------<-----<------<----<---------<------+ 550 FE loses association 552 Figure 4: The FE State Machine 554 In the mandated case, once associated, the FE can only be in one of 555 two states, as indicated above. When the FE is in the DOWN state, it 556 is not forwarding packets. When the FE is in the UP state it may be 557 forwarding packets, depending on the configuration of its specific 558 LFBs. The FE MAY also be in other states when it is capable of 559 graceful restart and high availaibility. The extra transitions are 560 explained in Section 8 and not discussed here so as to allow us to 561 explain the basics with more clarity. 563 The CE configures FE state transitions by means of the FE Object LFB, 564 which is defined in [FE-MODEL] and also explained in Section 7.2.2. 565 In the FE Object LFB, FE state is defined as an attribute of the LFB, 566 and CE configuration of the FE state equals CE configuration of this 567 attribute. Note that even in the FE DOWN state, the FE is 568 associated. 570 The FE stays in the DOWN state until it is explicitly configured by 571 the CE to transition to the UP state via an FE Object admin action. 572 This must be done before configuring any other LFBs that affect 573 packet forwarding. The typical setup will bring up the FE to the UP 574 state on association. 576 The FE transitions from the UP state to the DOWN state when it 577 receives an FEObject Admin Down action. when it loses its association 578 with the CE it may go into the pre-association phase depending on the 579 programmed policy. For the FE to properly complete the transition to 580 the DOWN state, it MUST stop Packet forwarding and this may impact 581 multiple LFBS. How this is achieved is outside the scope of this 582 specification. 584 4.2.1. Pre-association 586 The ForCES interface is configured during the pre-association phase. 587 In a simple setup, the configuration is static and is read from a 588 saved configuration file. All the parameters for the association 589 phase are well known after the pre-association phase is complete. A 590 protocol such as DHCP may be used to retrieve the configuration 591 parameters instead of reading them from a static configuration file. 592 Note, this will still be considered static pre-association. Dynamic 593 configuration may also happen using the Fc, Ff and Fl reference 594 points (refer to [RFC3746]). Vendors may use their own proprietary 595 service discovery protocol to pass the parameters. Essentially, only 596 guidelines are provided here and the details are left to the 597 implementation. 599 The following are scenarios reproduced from the Framework Document to 600 show a pre-association example. 602 <----Ff ref pt---> <--Fc ref pt-------> 603 FE Manager FE CE Manager CE 604 | | | | 605 | | | | 606 (security exchange) (security exchange) 607 1|<------------>| authentication 1|<----------->|authentication 608 | | | | 609 (FE ID, attributes) (CE ID, attributes) 610 2|<-------------| request 2|<------------|request 611 | | | | 612 3|------------->| response 3|------------>|response 613 (corresponding CE ID) (corresponding FE ID) 614 | | | | 615 | | | | 617 Figure 5: Examples of a message exchange over the Ff and Fc reference 618 points 620 <-----------Fl ref pt--------------> | 622 FE Manager FE CE Manager CE 623 | | | | 624 | | | | 625 (security exchange) | | 626 1|<------------------------------>| | 627 | | | | 628 (a list of CEs and their attributes) | 629 2|<-------------------------------| | 630 | | | | 631 (a list of FEs and their attributes) | 632 3|------------------------------->| | 633 | | | | 634 | | | | 636 Figure 6: An example of a message exchange over the Fl reference 637 point 639 Before the transition to the association phase, the FEM will have 640 established contact with a CEM component. Initialization of the 641 ForCES interface will have completed, and authentication as well as 642 capability discovery may be complete. Both the FE and CE would have 643 the necessary information for connecting to each other for 644 configuration, accounting, identification, and authentication 645 purposes. To summarize, at the completion of this stage both sides 646 have all the necessary protocol parameters such as timers, etc. The 647 Fl reference point may continue to operate during the association 648 phase and may be used to force a disassociation of an FE or CE. 649 Because the pre-association phase is out of scope, these details are 650 not discussed any further in this specification. The reader is 651 referred to the framework document [RFC3746] for a slightly more 652 detailed discussion. 654 4.2.2. Post-association 656 In this phase, the FE and CE components communicate with each other 657 using the ForCES protocol (PL over TML) as defined in this document. 658 There are three sub-phases: 660 o Association Setup Stage 662 o Established Stage 663 o Association Lost Stage 665 4.2.2.1. Association Setup Stage 667 The FE attempts to join the NE. The FE may be rejected or accepted. 668 Once granted access into the NE, capabilities exchange happens with 669 the CE querying the FE. Once the CE has the FE capability 670 information, the CE can offer an initial configuration (possibly to 671 restore state) and can query certain attributes within either an LFB 672 or the FE itself. 674 More details are provided in Section 4.4. 676 On successful completion of this stage, the FE joins the NE and is 677 moved to the Established Stage. 679 4.2.2.2. Established Stage 681 In this stage, the FE is continuously updated or queried. The FE may 682 also send asynchronous event notifications to the CE or synchronous 683 heartbeat notifications if programmed to do so. This stage continues 684 until a termination occurs, either due to loss of connectivity or due 685 to a termination initiated by either the CE or the FE. 687 Refer to the section on protocol scenarios, Section 4.4, for more 688 details. 690 4.2.2.3. Association Lost Stage 692 In this state, both or either the CE or FE declare the other side is 693 no longer associated. The disconnection could be initiated by either 694 party for administrative purposes but may also be driven by 695 operational reasons such as loss of connectivity. 697 A core LFB known as FE Protocol Object (FEPO) is defined (refer to 698 Appendix B and Section 7.2.1). FEPO defines various timers which can 699 be used in conjunction with traffic sensitive heartbeat mechanism 700 (Section 4.3.3) to detect loss of connectivity. 702 The loss of connectivity between TMLs does not indicate a loss of 703 association between respective PL layers. If the TML cannot repair 704 the transport loss before the programmed FEPO timer thresholds 705 associated with the FE is exceeded, then the association between the 706 respective PL layers will be lost. 708 FEPO defines several policies that can be programmed to define 709 behavior upon a detected loss of association. The FEPO's programmed 710 CE failover policy (refer to Section 8, Section 7.2.1, Section 4.3.3 711 and Appendix B) defines what takes place upon loss of association. 713 For this version of the protocol (as defined in this document), the 714 FE, upon re-association, MUST discard any state it has as invalid and 715 retrieve new state. This approach is motivated by a desire for 716 simplicity (as opposed to efficiency). 718 4.3. Protocol Mechanisms 720 Various semantics are exposed to the protocol users via the PL header 721 including: transaction capabilities, atomicity of transactions, two 722 phase commits, batching/parallelization, high availability and 723 failover as well as command pipelines. 725 The EM (Execute Mode) flag, AT (Atomic Transaction) flag, and TP 726 (Transaction Phase) flag as defined in the Common Header 727 (Section 6.1) are relevant to these mechanisms. 729 4.3.1. Transactions, Atomicity, Execution and Responses 731 In the master-slave relationship the CE instructs one or more FEs on 732 how to execute operations and how to report the results. 734 This section details the different modes of execution that a CE can 735 order the FE(s) to perform, as defined in Section 4.3.1.1. It also 736 describes the different modes a CE can ask the FE(s) to use for 737 formatting the responses after processing the operations as 738 requested. These modes relate to the transactional two phase 739 commitment operations. 741 4.3.1.1. Execution 743 There are 3 execution modes that can be requested for a batch of 744 operations spanning one or more LFB selectors (refer to 745 Section 7.1.1.1.5) in one protocol message. The EM flag defined in 746 the Common Header Section 6.1 selects the execution mode for a 747 protocol message, as below: 749 a. execute-all-or-none 751 b. execute-until-failure 753 c. continue-execute-on-failure 755 4.3.1.1.1. execute-all-or-none 757 When set to this mode of execution, independent operations in a 758 message MAY be targeted at one or more LFB selectors within an FE. 759 All these operations are executed serially and the FE MUST have no 760 execution failure for any of the operations. If any operation fails 761 to execute, then all the previous ones that have been executed prior 762 to the failure will need to be undone. I.e., there is rollback for 763 this mode of operation. 765 Refer to Section 4.3.1.2.2 for how this mode is used in cases of 766 transactions. In such a case, no operation is executed unless a 767 commit is issued by the CE. 769 Care should be taken on how this mode is used because a mis- 770 configuration could result in traffic losses. To add certainty to 771 the success of an operation, one should use this mode in a 772 transactional operation as described in Section 4.3.1.2.2 774 4.3.1.1.2. continue-execute-on-failure 776 If several independent operations are targeted at one or more LFB 777 selectors, execution continues for all operations at the FE even if 778 one or more operations fail. 780 4.3.1.1.3. execute-until-failure 782 In this mode all operations are executed on the FE sequentially until 783 the first failure. The rest of the operations are not executed but 784 operations already completed are not undone. I.e., there is no 785 rollback in this mode of operation. 787 4.3.1.2. Transaction and Atomicity 789 4.3.1.2.1. Transaction Definition 791 A transaction is defined as a collection of one or more ForCES 792 operations within one or more PL messages that MUST meet the ACIDity 793 properties [ACID], defined as: 795 Atomicity: In a transaction involving two or more discrete pieces 796 of information, either all of the pieces are committed 797 or none are. 799 Consistency: A transaction either creates a new and valid state of 800 data, or, if any failure occurs, returns all data to the 801 state it was in before the transaction was started. 803 Isolation: A transaction in process and not yet committed must 804 remain isolated from any other transaction. 806 Durability: Committed data is saved by the system such that, even in 807 the event of a failure and a system restart, the data is 808 available in its correct state. 810 There are cases where the CE knows exact memory and implementation 811 details of the FE such as in the case of an FE-CE pair from the same 812 vendor where the FE-CE pair is tightly coupled. In such a case, the 813 transactional operations may be simplified further by extra 814 computation at the CE. This view is not discussed further other than 815 to mention that it is not disallowed. 817 As defined above, a transaction is always atomic and MAY be 819 a. Within an FE alone 820 Example: updating multiple tables that are dependent on each 821 other. If updating one fails, then any that were already updated 822 must be undone. 824 b. Distributed across the NE 825 Example: updating table(s) that are inter-dependent across 826 several FEs (such as L3 forwarding related tables). 828 4.3.1.2.2. Transaction protocol 830 By use of the execute mode, as defined in Section 4.3.1.1, the 831 protocol has provided a mechanism for transactional operations within 832 one stand-alone message. The 'execute-all-or-none' mode can meet the 833 ACID requirements. 835 For transactional operations of multiple messages within one FE or 836 across FEs, a classical transactional protocol known as Two Phase 837 Commit (2PC) [2PCREF] is supported by the protocol to achieve the 838 transactional operations. 840 The AT flag and the TP flag in Common Header (Section 6.1) are 841 provided for 2PC-based transactional operations spanning multiple 842 messages. 844 The COMMIT operation is specified to be used in the case of a final 845 commit message. 847 The AT flag, when set, indicates this message belongs to an Atomic 848 Transaction. All messages for a transaction operation must have the 849 AT flag set. If not set, it means the message is a stand-alone 850 message and does not participate in any transaction operation that 851 spans multiple messages. 853 The TP flag indicates the Transaction Phase this message belongs to. 854 There are four (4) possible phases for an transactional operation 855 known as: 857 SOT (Start of Transaction) 859 MOT (Middle of Transaction) 861 EOT (End of Transaction) 863 ABT (Abort) 865 A transaction operation is started with a message the TP flag is set 866 to Start of Transaction (SOT). Multi-part messages, after the first 867 one, are indicated by the Middle of Transaction flag (MOT). All 868 messages from the CE MUST set the AlwaysACK flag (Section 6) to 869 solicit responses from the FE(s). 871 Before the CE issues a commit (described further below) the FE 872 only validates that the operation can be executed but does not 873 execute it. 875 Any failure notified by the FE causes the CE to execute an Abort 876 Transaction (ABT) to all FEs involved in the transaction, rolling 877 back any previously executed operations in the transaction (There 878 must be none if a commit has not been issued). 880 The transaction commitment phase is signaled from the CE to the FE 881 by an End of Transaction (EOT) configuration message with a COMMIT 882 operation. The FE MUST respond to the CE's EOT message. If no 883 response is received from the FE within a specified timeout, the 884 transaction MUST be aborted by the CE. 886 Note that a transactional operation is generically atomic, therefore 887 it requires that the execute modes of all messages in a transaction 888 operation should always be kept the same and be set to 'execute-all- 889 or-none'. If the EM flag is set to other execute modes, it will 890 result in a transaction failure. 892 As noted above, a transaction may span multiple messages. It is up 893 to the CE to keep track of the different outstanding messages making 894 up a transaction. As an example, the correlator field could be used 895 to mark transactions and a sequence field to label the different 896 messages within the same atomic transaction, but this is out of scope 897 and up to implementations. 899 Figure 9 shows an example of how a successful two phase commit 900 between a CE and an FE would look like. 902 4.3.1.2.3. Recovery 904 Any of the participating FEs, or the CE, or the associations between 905 them, may fail after the EOT response message has been sent by the FE 906 but before the CE has received all the responses, e.g. if the EOT 907 response never reaches the CE. 909 In this protocol revision, for sake of simplicity as indicated in 910 Section 4.2.2.3, an FE losing an association would be required to get 911 entirely new state from the newly associated CE upon a re- 912 association. The decision on what an FE should do after a lost 913 association is dictated by the CE Failover policy (refer to Section 8 914 and Section 7.2). 916 4.3.2. Scalability 918 It is desirable that the PL not become the bottleneck when larger 919 bandwidth pipes become available. To pick a hypothetical example in 920 today's terms, if a 100Gbps pipe is available and there is sufficient 921 work then the PL should be able to take advantage of this and use all 922 of the 100Gbps pipe. Two mechanisms have been provided to achieve 923 this. The first one is batching and the second one is a command 924 pipeline. 926 Batching is the ability to send multiple commands (such as Config) in 927 one Protocol Data Unit (PDU). The size of the batch will be affected 928 by, amongst other things, the path MTU. The commands may be part of 929 the same transaction or may be part of unrelated transactions that 930 are independent of each other. 932 Command pipelining allows for pipelining of independent transactions 933 which do not affect each other. Each independent transaction could 934 consist of one or more batches. 936 4.3.2.1. Batching 938 There are several batching levels at different protocol hierarchies. 940 o multiple PL PDUs can be aggregated under one TML message 942 o multiple LFB classes and instances (as indicated in the LFB 943 selector) can be addressed within one PL PDU 945 o Multiple operations can be addressed to a single LFB class and 946 instance 948 4.3.2.2. Command Pipelining 950 The protocol allows any number of messages to be issued by the CE 951 before the corresponding acknowledgments (if requested) have been 952 returned by the FE. Hence pipelining is inherently supported by the 953 protocol. Matching responses with requests messages can be done 954 using the correlator field in the message header. 956 4.3.3. Heartbeat Mechanism 958 Heartbeats (HB) between FEs and CEs are traffic sensitive. An HB is 959 sent only if no PL traffic is sent between the CE and FE within a 960 configured interval. This has the effect of reducing the amount of 961 HB traffic in the case of busy PL periods. 963 An HB can be sourced by either the CE or FE. When sourced by the CE, 964 a response can be requested (similar to the ICMP ping protocol). The 965 FE can only generate HBs in the case of being configured to do so by 966 the CE. Refer to Section 7.2.1 and Section 7.9 for details. 968 4.3.4. FE Object and FE Protocol LFBs 970 All PL messages operate on LFB constructs, as this provides more 971 flexibility for future enhancements. This means that maintenance and 972 configurability of FEs, NE, as well as the ForCES protocol itself 973 must be expressed in terms of this LFB architecture. For this reason 974 special LFBs are created to accommodate this need. 976 In addition, this shows how the ForCES protocol itself can be 977 controlled by the very same type of structures (LFBs) it uses to 978 control functions such as IP forwarding, filtering, etc. 980 To achieve this, the following specialized LFBs are introduced: 982 o FE Protocol LFB which is used to control the ForCES protocol. 984 o FE Object LFB which is used to control attributes relative to the 985 FE itself. Such attributes include FEState [FE-MODEL], vendor, 986 etc. 988 These LFBs are detailed in Section 7.2. 990 4.4. Protocol Scenarios 992 This section provides a very high level description of sample message 993 sequences between a CE and FE. For protocol message encoding refer 994 to Section 6.1 and for the semantics of the protocol refer to 995 Section 4.3. 997 4.4.1. Association Setup State 999 The associations among CEs and FEs are initiated via Association 1000 setup message from the FE. If a setup request is granted by the CE, 1001 a successful setup response message is sent to the FE. If CEs and 1002 FEs are operating in an insecure environment then the security 1003 associations have to be established between them before any 1004 association messages can be exchanged. The TML will take care of 1005 establishing any security associations. 1007 This is typically followed by capability query, topology query, etc. 1008 When the FE is ready to start forwarding data traffic, it sends an FE 1009 UP Event message to the CE. When the CE is ready, it responds by 1010 enabling the FE by setting the FEStatus to Adminup (Refer to 1011 [FE-MODEL] for details). This indicates to the FE to start 1012 forwarding data traffic. At this point the association establishment 1013 is complete. These sequences of messages are illustrated in the 1014 Figure 7 below. 1016 FE PL CE PL 1018 | | 1019 | Asso Setup Req | 1020 |---------------------->| 1021 | | 1022 | Asso Setup Resp | 1023 |<----------------------| 1024 | | 1025 | LFBx Query capability | 1026 |<----------------------| 1027 | | 1028 | LFBx Query Resp | 1029 |---------------------->| 1030 | | 1031 | FEO Query (Topology) | 1032 |<----------------------| 1033 | | 1034 | FEO Query Resp | 1035 |---------------------->| 1036 | | 1037 | FEO UP Event | 1038 |---------------------->| 1039 | | 1040 | Config FEO Adminup | 1041 |<----------------------| 1042 | | 1043 | FEO Config-Resp | 1044 |---------------------->| 1045 | | 1047 Figure 7: Message exchange between CE and FE to establish an NE 1048 association 1050 On successful completion of this state, the FE joins the NE. 1052 4.4.2. Association Established state or Steady State 1054 In this state, the FE is continously updated or queried. The FE may 1055 also send asynchronous event notifications to the CE, synchronous 1056 heartbeat messages, or packet redirect message to the CE. This 1057 continues until a termination (or deactivation) is initiated by 1058 either the CE or FE. Figure 8 below, helps illustrate this state. 1060 FE PL CE PL 1062 | | 1063 | Heart Beat | 1064 |<---------------------------->| 1065 | | 1066 | Heart Beat | 1067 |----------------------------->| 1068 | | 1069 | Config-set LFBy (Event sub.) | 1070 |<-----------------------------| 1071 | | 1072 | Config Resp LFBy | 1073 |----------------------------->| 1074 | | 1075 | Config-set LFBx Attr | 1076 |<-----------------------------| 1077 | | 1078 | Config Resp LFBx | 1079 |----------------------------->| 1080 | | 1081 |Config-Query LFBz (Stats) | 1082 |<--------------------------- -| 1083 | | 1084 | Query Resp LFBz | 1085 |----------------------------->| 1086 | | 1087 | FE Event Report | 1088 |----------------------------->| 1089 | | 1090 | Config-Del LFBx Attr | 1091 |<-----------------------------| 1092 | | 1093 | Config Resp LFBx | 1094 |----------------------------->| 1095 | | 1096 | Packet Redirect LFBx | 1097 |----------------------------->| 1098 | | 1099 | Heart Beat | 1100 |<-----------------------------| 1101 . . 1102 . . 1103 | | 1105 Figure 8: Message exchange between CE and FE during steady-state 1106 communication 1108 Note that the sequence of messages shown in the figure serve only as 1109 examples and the message exchange sequences could be different from 1110 what is shown in the figure. Also, note that the protocol scenarios 1111 described in this section do not include all the different message 1112 exchanges that would take place during failover. That is described 1113 in the HA section (Section 8) . 1115 4.4.3. Transaction messaging 1117 This section illustrates the message sequence of a successful 2PC 1118 between one CE and an FE. The case of the multiple FEs is left as an 1119 exercise for the reader 1121 FE PL CE PL 1123 | | 1124 | (1) Config, SOT,AT, EM=All-or-None, OP= SET/DEL,etc | 1125 |<-----------------------------------------------------| 1126 | | 1127 | (2) ACKnowledge | 1128 |----------------------------------------------------->| 1129 | | 1130 | (3) Config, MOT,AT, EM=All-or-None, OP= SET/DEL,etc | 1131 |<-----------------------------------------------------| 1132 | | 1133 | (4) ACKnowledge | 1134 |----------------------------------------------------->| 1135 | | 1136 | (5) Config, MOT,AT, EM=All-or-None, OP= SET/DEL,etc | 1137 |<-----------------------------------------------------| 1138 | | 1139 | (6) ACKnowledge | 1140 |----------------------------------------------------->| 1141 . . 1142 . . 1143 . . 1144 . . 1145 | | 1146 | (N) Config, EOT,AT, EM=All-or-None, OP= COMMIT | 1147 |<-----------------------------------------------------| 1148 | | 1149 | (N+1)Config-response, ACKnowledge, COMMIT-RESPONSE | 1150 |----------------------------------------------------->| 1152 Figure 9: Example of a two phase commit 1154 The flow of for a 2PC message sequence is described with more clarity 1155 in section Section 4.3.1.2.2. For the scenario illustrated above: 1157 o In step #1, the CE issues a Config message with an operation of 1158 choice like a DEL or SET. The transactional flag are set to 1159 indicate a Start of Transaction (SOT), Atomic Transaction (AT), 1160 execute-all-or-none. 1162 o The FE validates that it can execute the request successfully and 1163 then issues an acknowledgment back to the the CE in step #2. 1165 o In step #3, the same sort of construct as in step #1 is repeated 1166 by the CE with the transaction flag changed to Middle of 1167 Transaction(MOT). 1169 o The FE validates that it can execute the request successfully and 1170 then issues an acknowledgment back to the the CE in step #4. 1172 o The CE-FE exchange continues in the same manner until all the 1173 operations and their parameters are transferred to the FE. This 1174 happens in step #(N-1). 1176 o In step #N, the CE issues a commit. A commit is a config message 1177 with an operation of type COMMIT. The transactional flags are set 1178 to End of Transaction (EOT). Essentially, this is an "empty" 1179 message asking the FE to execute all the operations it has 1180 gathered since the beginning of the transaction (message #1). 1182 o The FE at this point executes the full transaction. It then 1183 issues an acknowledgment back to the the CE in step #(N+1) which 1184 contains a COMMIT-RESPONSE. 1186 5. TML Requirements 1188 The requirements below are expected to be delivered by the TML. This 1189 text does not define how such mechanisms are delivered. As an 1190 example they could be defined to be delivered via hardware or between 1191 2 or more TML processes on different CEs or FEs in protocol level 1192 schemes. 1194 Each TML must describe how it contributes to achieving the listed 1195 ForCES requirements. If for any reason a TML does not provide a 1196 service listed below a justification needs to be provided. 1198 1. Reliability 1199 As defined by RFC 3654, section 6 #6. 1201 2. Security 1202 TML provides security services to the ForCES PL. A TML layer 1203 should support the following security services and describe how 1204 they are achieved. 1206 * Endpoint authentication of FE and CE 1208 * Message authentication 1210 * Confidentiality service 1212 3. Congestion control 1213 The congestion control scheme used needs to be defined. The 1214 congestion control mechanism defined by the TML should prevent 1215 the FE from being overloaded by the CE or the CE from being 1216 overwhelmed by traffic from the FE. Additionally, the 1217 circumstances under which notification is sent to the PL to 1218 notify it of congestion must be defined. 1220 4. Uni/multi/broadcast addressing/delivery, if any 1221 If there is any mapping between PL and TML level uni/multi/ 1222 broadcast addressing it needs to be defined. 1224 5. HA decisions 1225 It is expected that availability of transport links is the TML's 1226 responsibility. However, based upon its configuration, the PL 1227 may wish to participate in link failover schemes and therefore 1228 the TML must support this capability. 1229 Please refer to Section 8 for details. 1231 6. Encapsulations used 1232 Different types of TMLs will encapsulate the PL messages on 1233 different types of headers. The TML needs to specify the 1234 encapsulation used. 1236 7. Prioritization 1237 It is expected that the TML will be able to handle up to 8 1238 priority levels needed by the PL and will provide preferential 1239 treatment. 1240 While the TML needs to define how this is achieved, it should be 1241 noted that the requirement for supporting up to 8 priority levels 1242 does not mean that the underlying TML MUST be capable of 1243 providing up to 8 actual priority levels. In the event that the 1244 underlying TML layer does not have support for 8 priority levels, 1245 the supported priority levels should be divided between the 1246 available TML priority levels. For example, if the TML only 1247 supports 2 priority levels, the 0-3 could go in one TML priority 1248 level, while 4-7 could go in the other. 1250 8. Protection against DoS attacks 1251 As described in RFC 3654, section 6 1253 5.1. TML Parameterization 1255 It is expected that it should be possible to use a configuration 1256 reference point, such as the FEM or the CEM, to configure the TML. 1258 Some of the configured parameters may include: 1260 o PL ID 1262 o Connection Type and associated data. For example if a TML uses 1263 IP/TCP/UDP, then parameters such as TCP and UDP port and IP 1264 addresses need to be configured. 1266 o Number of transport connections 1268 o Connection capability, such as bandwidth, etc. 1270 o Allowed/supported connection QoS policy (or congestion control 1271 policy) 1273 6. Message Encapsulation 1275 All PL PDUs start with a common header [Section 6.1] followed by a 1276 one or more TLVs [Section 6.2] which may nest other TLVs 1277 [Section 6.2.1]. All fields are in network byte order. 1279 6.1. Common Header 1281 0 1 2 3 1282 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 1283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1284 |version| rsvd | Message Type | Length | 1285 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1286 | Source ID | 1287 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1288 | Destination ID | 1289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1290 | Correlator | 1291 | | 1292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1293 | Flags | 1294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1296 Figure 10: Common Header 1298 The message is 32 bit aligned. 1300 Version (4 bit): 1301 Version number. Current version is 1. 1303 rsvd (4 bit): 1304 Unused at this point. A receiver should not interpret this 1305 field. Senders MUST set it to zero and receivers MUST ignore 1306 this field. 1308 Message Type (8 bits): 1309 Commands are defined in Section 7. 1311 Length (16 bits): 1312 length of header + the rest of the message in DWORDS (4 byte 1313 increments). 1315 Source ID (32 bit): 1317 Dest ID (32 bit): 1319 * Each of the source and destination IDs are 32 bit IDs which 1320 are unique NE-wide and which identify the termination points 1321 of a ForCES PL message. 1323 * IDs allow multi/broad/unicast addressing with the following 1324 approach: 1326 a. A split address space is used to distinguish FEs from 1327 CEs. Even though in a large NE there are typically two 1328 or more orders of magnitude more FEs than CEs, the 1329 address space is split uniformly for simplicity. 1331 b. The address space allows up to 2^30 (over a billion) CEs 1332 and the same amount of FEs. 1334 0 1 2 3 1335 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 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 |TS | sub-ID | 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 Figure 11: ForCES ID Format 1342 c. The 2 most significant bits called Type Switch (TS) are 1343 used to split the ID space as follows: 1345 TS Corresponding ID range Assignment 1346 -- ---------------------- ---------- 1347 0b00 0x00000000 to 0x3FFFFFFF FE IDs (2^30) 1348 0b01 0x40000000 to 0x7FFFFFFF CE IDs (2^30) 1349 0b10 0x80000000 to 0xBFFFFFFF reserved 1350 0b11 0xC0000000 to 0xFFFFFFEF multicast IDs (2^30 - 16) 1351 0b11 0xFFFFFFF0 to 0xFFFFFFFC reserved 1352 0b11 0xFFFFFFFD all CEs broadcast 1353 0b11 0xFFFFFFFE all FEs broadcast 1354 0b11 0xFFFFFFFF all FEs and CEs (NE) broadcast 1356 Figure 12: Type Switch ID Space 1358 * Multicast or broadcast IDs are used to group endpoints (such 1359 as CEs and FES). As an example one could group FEs in some 1360 functional group, by assigning a multicast ID. Likewise, 1361 subgroups of CEs that act, for instance, in a back-up mode 1362 may be assigned a multicast ID to hide them from the FE. 1364 + Multicast IDs can be used for both source or destination 1365 IDs. 1367 + Broadcast IDs can be used only for destination IDs. 1369 * This document does not discuss how a particular multicast ID 1370 is associated to a given group though it could be done via 1371 configuration process. The list of IDs an FE owns or is part 1372 of are listed on the FE Object LFB. 1374 Correlator (64 bits) 1375 This field is set by the CE to correlate ForCES Request Messages 1376 with the corresponding Response messages from the FE. 1377 Essentially it is a cookie. The correlator is handled 1378 transparently by the FE, i.e., for a particular Request message 1379 the FE MUST assign the same correlator value in the corresponding 1380 Response message. In the case where the message from the CE does 1381 not elicit a response, this field may not be useful. 1383 The correlator field could be used in many implementations 1384 specific ways by the CE. For example, the CE could split the 1385 correlator into a 32-bit transactional identifier and 32-bit 1386 message sequence identifier. Another example is a 64-bit pointer 1387 to a context block. All such implementation specific use of the 1388 correlator is outside the scope of this specification. 1390 Whenever the correlator field is not relevant, because no message 1391 is expected, the correlator field is set to 0. 1393 Flags(32 bits): 1394 Identified so far: 1396 0 1 2 3 1397 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 1398 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1399 | | | | | | | | 1400 |ACK| Pri |Rsr |EM |A|TP | Reserved | 1401 | | | vd. | |T| | | 1402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 Figure 13: Header Flags 1406 - ACK: ACK indicator (2 bit) 1407 The ACK indicator flag is only used by the CE when sending a 1408 Config Message (Section 7.5.1) or a HB message (Section 7.9) 1409 to indicate to the message receiver whether or not a response 1410 is required by the sender. Note that for all other messages 1411 than the Config Message or the HB Message this flag MUST be 1412 ignored. 1414 The flag values are defined as below: 1416 'NoACK' (0b00) - to indicate that the message receiver 1417 MUST not to send any response message back to this 1418 message sender. 1420 'SuccessACK'(0b01) - to indicate the message receiver 1421 MUST send a response message back only when the message 1422 has been successfully processed by the receiver. 1424 'FailureACK'(0b10) - to indicate the message receiver 1425 MUST send a response message back only when there is 1426 failure by the receiver in processing (executing) the 1427 message. In other words, if the message can be processed 1428 successfully, the sender will not expect any response 1429 from the receiver. 1431 'AlwaysACK' (0b11) - to indicate the message receiver 1432 MUST send a response message. 1434 Note that in above definitions, the term success implies a 1435 complete execution without any failure of the message. 1436 Anything else than a complete successful execution is defined 1437 as a failure for the message processing. As a result, for 1438 the execution modes (defined in Section 4.3.1.1) like 1439 execute-all-or-none, execute-until-failure, and continue- 1440 execute-on-failure, if any single operation among several 1441 operations in the same message fails, it will be treated as a 1442 failure and result in a response if the ACK indicator has 1443 been set to 'FailureACK' or 'AlwaysACK'. 1445 Also note that, other than in Config and HB Messages, 1446 requirements for responses of messages are all given in a 1447 default way rather than by ACK flags. The default 1448 requirements of these messages and the expected responses are 1449 summarized below. Detailed descriptions can be found in the 1450 individual message definitions: 1452 + Association Setup Message always expects a response. 1454 + Association Teardown Message, and Packet Redirect 1455 Message, never expect responses. 1457 + Query Message always expects a response. 1459 + Response message never expects further responses. 1461 - Pri: Priority (3 bits) 1462 ForCES protocol defines 8 different levels of priority (0-7). 1463 The priority level can be used to distinguish between 1464 different protocol message types as well as between the same 1465 message type. The higher the priority value, the more 1466 important the PDU is. For example, the REDIRECT packet 1467 message could have different priorities to distinguish 1468 between routing protocols packets and ARP packets being 1469 redirected from FE to CE. The Normal priority level is 1. 1470 The different priorities imply messages could be re-ordered; 1471 however, re-ordering is undesirable when it comes to a set of 1472 messages within a transaction and caution should be exercised 1473 to avoid this from happening. 1475 - EM: Execution Mode (2 bits) 1476 There are 3 execution modes refer to Section 4.3.1.1 for 1477 details. 1479 Reserved..................... (0b00) 1481 `execute-all-or-none` ....... (0b01) 1483 `execute-until-failure` ..... (0b10) 1485 `continue-execute-on-failure` (0b11) 1487 - AT: Atomic Transaction (1 bit) 1488 This flag indicates if the message is stand-alone message or 1489 one of multiple messages that belongs to 2PC transaction 1490 operations. See Section 4.3.1.2.2 for details. 1492 Stand-alone message ......... (0b0) 1494 2PC transaction message ..... (0b1) 1496 - TP: Transaction Phase (2 bits) 1497 A message from the CE to the FE within a transaction could be 1498 indicative of the different phases the transaction is in. 1499 Refer to Section 4.3.1.2.2 for details. 1501 SOT (start of transaction) ..... (0b00) 1503 MOT (Middle of transaction) .... (0b01) 1505 EOT (end of transaction) ........(0b10) 1507 ABT (abort) .....................(0b11) 1509 6.2. Type Length Value (TLV) Structuring 1511 TLVs are extensively used by the ForCES protocol. TLVs have some 1512 very nice properties which make them a good candidate for encoding 1513 the XML definitions of the LFB class model. These are: 1515 o Providing for binary type-value encoding that is close to the XML 1516 string tag-value scheme. 1518 o Allowing for fast generalized binary-parsing functions. 1520 o Allowing for forward and backward tag compatibility. This is 1521 equivalent to the XML approach i.e old applications can ignore new 1522 TLVs and newer applications can ignore older TLVs. 1524 0 1 2 3 1525 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 1526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1527 | TLV Type | TLV Length | 1528 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1529 | Value (Essentially the TLV Data) | 1530 ~ ~ 1531 ~ ~ 1532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1534 Figure 14: TLV Representation 1536 TLV Type (16): 1537 The TLV type field is two octets, and semantically 1538 indicates the type of data encapsulated within the 1539 TLV. 1541 TLV Length (16): 1542 The TLV length field is two octets, and includes the 1543 length of the TLV type (2 octets), TLV Length (2 1544 octets), and the length of the TLV data found in the 1545 value field, in octets. Note that this length is 1546 the actual length of the value, before any padding 1547 for alignment is added. 1549 TLV Value (variable): 1550 The TLV value field carries the data. For 1551 extensibility, the TLV value may in fact be a TLV. 1552 Padding is required when the length is not a 1553 multiple of 32 bits, and is the minimum number of 1554 bytes required to bring the TLV to a multiple of 32 1555 bits. The length of the value before padding is 1556 indicated by the TLV Length field. Note: The value 1557 field could be empty which implies the minimal 1558 length a TLV could be is 4 (length of "T" field and 1559 length of "L" field). 1561 6.2.1. Nested TLVs 1563 TLV values can be other TLVs. This provides the benefits of protocol 1564 flexibility (being able to add new extensions by introducing new TLVs 1565 when needed). The nesting feature also allows for a conceptual 1566 optimization with the XML LFB definitions to binary PL representation 1567 (represented by nested TLVs). 1569 6.2.2. Scope of the T in TLV 1571 The "Type" values in the TLV are global in scope. This means that 1572 wherever TLVs occur in the PDU, a specific Type value refers to the 1573 same Type of TLV. This is a design choice that was made to ease 1574 debugging of the protocol. 1576 6.3. ILV 1578 A slight variation of the TLV known as the ILV. This sets the type 1579 ("T") to be a 32-bit local index that refers to a ForCES element ID. 1580 (refer to Section 6.4.1). The Length part of the ILV is fixed at 32 1581 bits. 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1584 | Identifier | 1585 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1586 | Length | 1587 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1588 | Value | 1589 . . 1590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1592 Figure 15: ILV Representation 1594 It should be noted that the "I" values are of local scope and are 1595 defined by the data declarations from the LFB definition. Refer to 1596 Section 7.1.1.1.8 for discussions on usage of ILVs. 1598 6.4. Important Protocol encapsulations 1600 In this section, we review a few encapsulation concepts that are used 1601 by the ForCES protocol for its operations. 1603 We briefly re-introduce two concepts, Paths and Keys, from the model 1604 draft [FE-MODEL] in order to provide context. The reader is refered 1605 to [FE-MODEL] for a lot of the finer details. 1607 For readability reasons, we introduce the encapsulation schemes that 1608 are used to carry content in a protocol message, namely FULLDATA, 1609 SPARSEDATA, and RESULT TLVs. 1611 6.4.1. Paths 1613 The model draft [FE-MODEL] defines an XML-based language that allows 1614 for a formal definition of LFBs. This is similar to the relationship 1615 between ASN.1 and SNMP MIB definition (MIB being analogous to the LFB 1616 and ASN.1 being analogous to the XML model language). Any entity 1617 that the CE configures on an FE MUST be formally defined in an LFB. 1618 These entities could be scalars (e.g., a 32-bit IPv4 address) or 1619 vectors (such as a nexthop table). Each entity within the LFB is 1620 given a numeric 32-bit identifier known as an "element id". This 1621 scheme allows the attribute to be "addressed" in a protocol 1622 construct. 1624 These addressable entities could be hierachical (e.g., a table column 1625 or a cell within a table row). In order to address hierachical data, 1626 the concept of a path is introduced by the model [FE-MODEL]. A path 1627 is a series of 32-bit element IDs which are typically presented in a 1628 dot-notation (e.g., 1.2.3.4). The protocol grammar (Section 7.1) 1629 formally defines how paths are used to reference data that is being 1630 encapsulated within a protocol message. 1632 6.4.2. Keys 1634 The model draft [FE-MODEL] defines two ways to address table rows. 1635 The standard/common mechanism is to allow table rows to be referenced 1636 by a 32-bit index. The secondary mechanism is via Keys which allow 1637 for content addressing. An example key is a multi-field content key 1638 that uses the IP address and prefix length to uniquely reference an 1639 IPv4 routing table row. In essence, while the common scheme to 1640 address a table row is via its table index, a table row's path could 1641 be derived from a key. The KEYINFO TLV (Section 7.1) is used to 1642 carry the data that is used to do the lookup. 1644 6.4.3. DATA TLVs 1646 Data from or to the FE is carried in two types of TLVs: FULLDATA TLV 1647 and SPARSEDATA TLV. Responses on operations executed by the FE are 1648 carried in RESULT TLVs. 1650 In FULLDATA TLV, the data is encoded in such a way that a receiver of 1651 such data, by virtue of being armed with knowledge of the path and 1652 the LFB definition, can infer or correlate the TLV "Value" contents. 1653 This is essentially an optimization that helps reduce the amount of 1654 description required for the transported data in the protocol 1655 grammar. Refer to Appendix C for an example of FULLDATA TLVs. 1657 A number of operations in ForCES will need to reference optional data 1658 within larger structures. The SPARSEDATA TLV encoding is provided to 1659 make it easier to encapsulate optionally appearing data elements. 1660 Refer to Appendix C for an example of SPARSEDATA TLV. 1662 RESULT TLVs carry responses back from the FE based on a config issued 1663 by the CE. Refer to Appendix C for examples of RESULT TLVs and 1664 Section 7.1.1.1.7 for layout. 1666 6.4.4. Addressing LFB entities 1668 Section 6.4.1 and Section 6.4.2 discuss how to target an entity 1669 within an LFB. However, the addressing mechanism used requires that 1670 an LFB type and instance is selected first. The LFB Selector is used 1671 to select an LFB type and instance being targeted. The protocol 1672 grammar (Section 7.1) goes into more details; for our purpose, we 1673 illustrate this concept using Figure 16 below. More examples of 1674 layouts can be found reading further into the text (Example: 1675 Figure 21). 1677 main hdr (Message type: example "config") 1678 | 1679 | 1680 | 1681 +- T = LFBselect 1682 | 1683 +-- LFBCLASSID (unique per LFB defined) 1684 | 1685 | 1686 +-- LFBInstance (runtime configuration) 1687 | 1688 +-- T = An operation TLV describes what we do to an entity 1689 | //Refer to the OPERSELECT values enumerated below 1690 | //the TLVs that can be used for operations 1691 | 1692 | 1693 +--+-- one or more path encodings to target an entity 1694 | // Refer to the discussion on keys and paths 1695 | 1696 | 1697 +-- The associated data, if any, for the entity 1698 // Refer to discussion on FULL/SPARSE DATA TLVs 1700 Figure 16: Entity Addressing 1702 7. Protocol Construction 1704 7.1. Protocol Grammar 1706 The protocol construction is formally defined using a BNF-like syntax 1707 to describe the structure of the PDU layout. This is matched to a 1708 precise binary format later in the document. 1710 Since the protocol is very flexible and hierarchical in nature, it is 1711 easier at times to see the visualization layout. This is provided in 1712 Section 7.1.2 1714 7.1.1. Protocol BNF 1716 The format used is based on [RFC2234]. The terminals of this grammar 1717 are flags, IDcount, IDs, KEYID, and encoded data, described after the 1718 grammar. 1720 1. A TLV will have the word "-TLV" suffix at the end of its name 1722 2. An ILV will have the word "-ILV" suffix at the end of its name 1724 3. / is used to separate alternatives 1726 4. parenthesized elements are treated as a single item 1728 5. * before an item indicates 0 or more repetitions 1730 6. 1* before an item indicates 1 or more repetitions 1732 7. [] around an item indicates that it is optional (equal to 1*) 1734 The BNF of the PL level PDU is as follows: 1736 PL level PDU := MAINHDR MAINSELECT 1737 MAINHDR := The PL PDU header defined in section "Common Header" 1738 MAINSELECT := ASSOCIATION / ASSOCIATION-RESP / ASSOCIATION-TEAR / 1739 CONFIG / CONFIG-RESP / QUERY / QUERY-RESP / 1740 EVENT / REDIRECT / HEARTBEAT 1741 ASSOCIATION := LFBselect-TLV 1742 ASSOCIATION-RESP := ASResult-TLV 1743 ASSOCIATION-TEAR := ASTreason-TLV 1744 CONFIG := 1*[LFBselect-TLV] 1745 CONFIG-RESP := 1*[LFBselect-TLV] 1746 QUERY := LFBselect-TLV 1747 QUERY-RESP := LFBselect-TLV 1748 EVENT := LFBselect-TLV 1749 REDIRECT := REDIRECT-TLV 1750 HEARTBEAT := empty message as described in section "Heartbeat Message" 1751 LFBselect-TLV := LFBCLASSID LFBInstance 1*OPERSELECT 1752 LFBCLASSID := the LFB Class ID 1753 LFBInstance := the instance of the LFB class 1754 ASResult-TLV := carries the Association Setup result code 1755 ASTreason-TLV := carries the Association Teardown reason 1756 OPERSELECT := 1*PATH-DATA-TLV 1757 PATH-DATA-TLV := PATH [DATA] 1758 PATH := flags IDcount IDs [SELECTOR] 1759 SELECTOR := KEYINFO-TLV 1760 DATA := FULLDATA-TLV / SPARSEDATA-TLV / RESULT-TLV / 1761 1*PATH-DATA-TLV 1762 KEYINFO-TLV := Keyid FULLDATA-TLV 1763 FULLDATA-TLV := encoded data element which may nest 1764 further FULLDATA-TLVs 1765 SPARSEDATA-TLV := encoded data that may have optionally 1766 appearing elements 1767 RESULT-TLV := Holds result code and optional FULLDATA-TLV 1769 Figure 17: BNF of PL level PDU 1771 o MAINHDR defines a message type, Target FE/CE ID etc. The MAINHDR 1772 also defines the content. As an example the content of a "config" 1773 message would be different from an "association" message. The 1774 table below illustrates the different message types. 1776 +----------------------------+--------------+---------------+ 1777 | Message Name | Numeric Type | Reference | 1778 +----------------------------+--------------+---------------+ 1779 | Association Setup | 0x1 | Section 7.4.1 | 1780 | | | | 1781 | Association Setup Response | 0x11 | Section 7.4.2 | 1782 | | | | 1783 | Association Teardown | 0x02 | Section 7.4.3 | 1784 | | | | 1785 | Config | 0x03 | Section 7.5.1 | 1786 | | | | 1787 | Config Response | 0x13 | Section 7.5.2 | 1788 | | | | 1789 | Query | 0x04 | Section 7.6.1 | 1790 | | | | 1791 | Query Response | 0x14 | Section 7.6.2 | 1792 | | | | 1793 | Event Notification | 0x05 | Section 7.7 | 1794 | | | | 1795 | Packet Redirect | 0x06 | Section 7.8 | 1796 | | | | 1797 | Heartbeat | 0x0F | Section 7.9 | 1798 +----------------------------+--------------+---------------+ 1800 Table 1 1802 o MAINSELECT is a place holder to select one of several TLVs that 1803 could follow the common header. The appearance of these TLVs is 1804 message type specific and is demonstrated in the table below. 1806 +----------------+------------+-------------------------------------+ 1807 | Message | MAINSELECT | OPERSELECT | 1808 +----------------+------------+-------------------------------------+ 1809 | Association | LFBselect | REPORT | 1810 | Setup | | | 1811 | | | | 1812 | Association | ASRresult | None | 1813 | Setup Response | | | 1814 | | | | 1815 | Association | ASTreason | None | 1816 | Teardown | | | 1817 | | | | 1818 | Config | LFBselect | SET, DEL, COMMIT, SET-PROPERTY | 1819 | | | | 1820 | Config | LFBselect | SET-RESPONSE, DEL-RESPONSE, | 1821 | Response | | SET-PROPERTY-RESPONSE, | 1822 | | | COMMIT-RESPONSE | 1823 | | | | 1824 | Query | LFBselect | GET, GET-PROPERTY | 1825 | | | | 1826 | Query Response | LFBselect | GET-RESPONSE, GET-PROPERTY-RESPONSE | 1827 | | | | 1828 | Event | LFBselect | REPORT | 1829 | Notification | | | 1830 | | | | 1831 | Packet | Redirect | None | 1832 | Redirect | | | 1833 | | | | 1834 | Heartbeat | None | None | 1835 +----------------+------------+-------------------------------------+ 1837 Table 2 1839 o When an LFB class is defined, it is assigned a unique value as an 1840 identifier. LFBCLASSID contains such an identifier. 1842 o LFBInstance is the identifier of a particular instance of an LFB 1843 class. 1845 o OPERSELECT is a place holder in the grammar to select the TLV to 1846 uniquely identify the type of operation. 1848 o LFBselect is a TLV that is used by some messages as shown in the 1849 grammar above. Table 2 illustrates what each message type could 1850 have in terms of MAINSELECT and OPERSELECT restrictions. 1852 o PATH-DATA-TLV identifies the exact element targeted and may have 1853 zero or more paths associated with it. The last PATH-DATA-TLV in 1854 the case of nesting of paths via the DATA construct in the case of 1855 SET, SET-PROPERTY requests and GET-RESPONSE/GET-PROPERTY-RESPONSE 1856 is terminated by encoded data or response in the form of either 1857 FULLDATA-TLV or SPARSEDATA-TLV or RESULT-TLV. 1859 o PATH provides the path to the data being referenced. 1861 * flags (16 bits) are used to further refine the operation to be 1862 applied on the Path. More on these later. 1864 * IDcount(16 bit): count of 32 bit IDs 1866 * IDs: zero or more 32bit IDs (whose count is given by IDcount) 1867 defining the main path. Depending on the flags, IDs could be 1868 field IDs only or a mix of field and dynamic IDs. Zero is used 1869 for the special case of using the entirety of the containing 1870 context as the result of the path. 1872 o SELECTOR is an optional construct that further defines the PATH. 1873 Currently, the only defined selector is the KEYINFO-TLV, used for 1874 selecting an array entry by the value of a key field. The 1875 presence of a SELECTOR is correct only when the flags also 1876 indicate its presence. A mismatch is a protocol format error. 1878 o A KEYINFO TLV contains information used in content keying. 1880 * A KeyID is used in a KEYINFO TLV. It indicates which key for 1881 the current array is being used as the content key for array 1882 entry selection. 1884 * The key's data is the data to look for in the array, in the 1885 fields identified by the key field. The information is encoded 1886 according to the rules for the contents of a FULLDATA-TLV, and 1887 represent the field or fields which make up the key identified 1888 by the KEYID. 1890 o DATA may contain a FULLDATA-TLV, SPARSEDATA-TLV, a RESULT-TLV or 1 1891 or more further PATH-DATA selection. FULLDATA and SPARSEDATA are 1892 only allowed on SET or SET-PROPERTY requests, or on responses 1893 which return content information (GET-RESPONSE for example). 1894 PATH-DATA may be included to extend the path on any request. 1896 * Note: Nested PATH-DATA TLVs are supported as an efficiency 1897 measure to permit common subexpression extraction. 1899 * FULLDATA and SPARSEDATA contain "the data" whose path has been 1900 selected by the PATH. Refer to Section 7.1.1.1 for details. 1902 * The following table summarizes the applicability and 1903 restrictions of the FULL/SPARSEDATA TLV and the RESULT TLV to 1904 the OPERSELECTs. 1906 +-----------------------+-------------+----------------+------------+ 1907 | OPERSELECT | FULLDATA | SPARSEDATA TLV | RESULT TLV | 1908 | | TLV | | | 1909 +-----------------------+-------------+----------------+------------+ 1910 | SET | MAY | MAY | MUST NOT | 1911 | | | | | 1912 | SET-PROPERTY | MAY | MAY | MUST NOT | 1913 | | | | | 1914 | SET-RESPONSE | MAY | MUST NOT | MUST | 1915 | | | | | 1916 | SET-PROPERTY-RESPONSE | MAY | MAY | MUST NOT | 1917 | | | | | 1918 | DEL | MAY | MAY | MUST NOT | 1919 | | | | | 1920 | DEL-RESPONSE | MAY | MUST NOT | MUST | 1921 | | | | | 1922 | GET | MUST NOT | MUST NOT | MUST NOT | 1923 | | | | | 1924 | GET-PROPERTY | MUST NOT | MUST NOT | MUST NOT | 1925 | | | | | 1926 | GET-RESPONSE | MUST | MUST NOT | MAY | 1927 | | | | | 1928 | GET-PROPERTY-RESPONSE | MUST | MUST NOT | MAY | 1929 | | | | | 1930 | REPORT | MAY | MUST NOT | MUST NOT | 1931 | | | | | 1932 | COMMIT | MUST NOT | MUST NOT | MUST NOT | 1933 | | | | | 1934 | COMMIT-RESPONSE | MUST NOT | MUST NOT | MAY | 1935 +-----------------------+-------------+----------------+------------+ 1937 Table 3 1939 o RESULT contains the indication of whether the individual SET or 1940 SET-PROPERTY succeeded. If there is a request for verbose 1941 response, then SET-RESPONSE or SET-PROPERTY-RESPONSE will also 1942 contain the FULLDATA TLV showing the data that was set. RESULT- 1943 TLV is included on the assumption that individual parts of a SET 1944 request can succeed or fail separately. 1946 In summary this approach has the following characteristic: 1948 o There can be one or more LFB class ID and instance ID combination 1949 targeted in a message (batch) 1951 o There can one or more operations on an addressed LFB class ID/ 1952 instance ID combination (batch) 1954 o There can be one or more path targets per operation (batch) 1956 o Paths may have zero or more data values associated (flexibility 1957 and operation specific) 1959 It should be noted that the above is optimized for the case of a 1960 single LFB class ID and instance ID targeting. To target multiple 1961 instances within the same class, multiple LFBselects are needed. 1963 7.1.1.1. Discussion on encoding 1965 Section 6.4.3 discusses the two types of DATA encodings (FULLDATA and 1966 SPARSEDATA TLV) and the justifications for their existence. In this 1967 section we explain how they are encoded. 1969 7.1.1.1.1. Data Packing Rules 1971 The scheme for encoding data used in this doc adheres to the 1972 following rules: 1974 o The Value ("V" of TLV) of FULLDATA TLV will contain the data being 1975 transported. This data will be as was described in the LFB 1976 definition. 1978 o Variable sized data within a FULLDATA TLV will be encapsulated 1979 inside another FULLDATA TLV inside the V of the outer TLV. For 1980 example of such a setup refer to Appendix C and Appendix D 1982 o In the case of FULLDATA TLVs: 1984 * When a table is referred to in the PATH (IDs) of a PATH-DATA- 1985 TLV, then the FULLDATA's "V" will contain that table's row 1986 content prefixed by its 32 bit index/subscript. On the other 1987 hand, when PATH flags are 00, the PATH may contain an index 1988 pointing to a row in table; in such a case, the FULLDATA's "V" 1989 will only contain the content with the index in order to avoid 1990 ambiguity. 1992 7.1.1.1.2. Path Flags 1994 The following flags are currently defined: 1996 o SELECTOR Bit: F_SELKEY indicates that a KEY Selector is present 1997 following this path information, and should be considered in 1998 evaluating the path. 2000 o FIND-EMPTY Bit: This must not be set if the F_SEL_KEY bit is set. 2001 This must only be used on a create operation. If set, this 2002 indicates that although the path identifies an array, the SET 2003 operation should be applied to the first unused element in the 2004 array. The result of the operation will not have this flag set, 2005 and will have the assigned index in the path. 2007 Example: For a given LFB class, the path 2.5 might select an 2008 array in a structure. If one wanted to set element 6 in this 2009 array, then the path 2.5.6 would define that element. However 2010 if one wanted to create an element in the first empty spot in 2011 the array, the CE would then send the TLV with the FIND-EMPTY 2012 bit set with the path set to 2.5. Essentially,this is an 2013 optimization so as to not require the CE to fully track all the 2014 tables. 2016 7.1.1.1.3. Relation of operational flags with global message flags 2018 Global flags, such as the execution mode and the atomicity indicators 2019 defined in the header, apply to all operations in a message. Global 2020 flags provide semantics that are orthogonal to those provided by the 2021 operational flags, such as the flags defined in Path Data. The scope 2022 of operational flags is restricted to the operation. 2024 7.1.1.1.4. Content Path Selection 2026 The KEYINFO TLV describes the KEY as well as associated KEY data. 2027 KEYs, used for content searches, are restricted and described in the 2028 LFB definition. 2030 7.1.1.1.5. LFBselect-TLV 2032 The LFBselect TLV is an instance of a TLV as defined in Section 6.2. 2033 The definition is as below: 2035 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 2036 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2037 | Type = LFBselect | Length | 2038 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2039 | LFB Class ID | 2040 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2041 | LFB Instance ID | 2042 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2043 | OPERSELECT | 2044 . . 2045 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2046 ~ ... ~ 2047 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2048 | OPERSELECT | 2049 . . 2050 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2052 Figure 18: PL PDU layout 2054 Type: 2055 The type of the TLV is "LFBselect" 2057 Length: 2058 Length of the TLV including the T and L fields, in octets. 2060 LFB Class ID: 2061 This field uniquely recognizes the LFB class/type. 2063 LFB Instance ID: 2064 This field uniquely identifies the LFB instance. 2066 OPERSELECT: 2067 It describes an operation nested in the LFBselect TLV. Note that 2068 usually there SHOULD be at least one OPERSELECT present for an 2069 LFB select TLV, but for the Association Setup Message defined in 2070 Section 7.4.1. the OPERSELECT is optional. 2072 7.1.1.1.6. OPERSELECT 2074 The OPERSELECT is a place holder in the grammar for TLVs that define 2075 operations. The different types are defined in Table 4, below. 2077 +-----------------------+--------+----------------------------------+ 2078 | OPERSELECT | TLV | Comments | 2079 | | "Type" | | 2080 +-----------------------+--------+----------------------------------+ 2081 | SET | 0x0001 | From CE to FE. Used to create | 2082 | | | or add or update attributes | 2083 | | | | 2084 | SET-PROPERTY | 0x0002 | From CE to FE. Used to create | 2085 | | | or add or update attributes | 2086 | | | | 2087 | SET-RESPONSE | 0x0003 | From FE to CE. Used to carry | 2088 | | | response of a SET | 2089 | | | | 2090 | SET-PROPERTY-RESPONSE | 0x0004 | From FE to CE. Used to carry | 2091 | | | response of a SET-PROPERTY | 2092 | | | | 2093 | DEL | 0x0005 | From CE to FE. Used to delete | 2094 | | | or remove an attribute | 2095 | | | | 2096 | DEL-RESPONSE | 0x0006 | From FE to CE. Used to carry | 2097 | | | response of a DEL | 2098 | | | | 2099 | GET | 0x0007 | From CE to FE. Used to retrieve | 2100 | | | an attribute | 2101 | | | | 2102 | GET-PROPERTY | 0x0008 | From CE to FE. Used to retrieve | 2103 | | | an attribute property | 2104 | | | | 2105 | GET-RESPONSE | 0x0009 | From FE to CE. Used to carry | 2106 | | | response of a GET | 2107 | | | | 2108 | GET-PROPERTY-RESPONSE | 0x000A | From FE to CE. Used to carry | 2109 | | | response of a GET-PROPERTY | 2110 | | | | 2111 | REPORT | 0x000B | From FE to CE. Used to carry an | 2112 | | | asynchronous event | 2113 | | | | 2114 | COMMIT | 0x000C | From CE to FE. Used to issue a | 2115 | | | commit in a 2PC transaction | 2116 | | | | 2117 | COMMIT-RESPONSE | 0x000D | From an FE to CE. Used to | 2118 | | | confirm a commit in a 2PC | 2119 | | | transaction | 2120 +-----------------------+--------+----------------------------------+ 2122 Table 4 2124 Different messages define OPERSELECT are valid and how they are used 2125 (refer to Table 2 and Table 3). 2127 SET, SET-PROPERTY, and GET/GET-PROPERTY requests are issued by the CE 2128 and do not carry RESULT TLVs. On the other hand, SET-RESPONSE, SET- 2129 PROPERTY-RESPONSE and GET-RESPONSE/GET-PROPERTY-RESPONSE carry RESULT 2130 TLVs. 2132 A GET-RESPONSE in response to a successful GET will have FULLDATA 2133 TLVs added to the leaf paths to carry the requested data. For GET 2134 operations that fail, instead of the FULLDATA TLV there will be a 2135 RESULT TLV. 2137 For a SET-RESPONSE/SET-PROPERTY-RESPONSE, each FULLDATA or SPARSEDATA 2138 TLV in the original request will be replaced with a RESULT TLV in the 2139 response. If the request set the FailureACK flag, then only those 2140 items which failed will appear in the response. If the request was 2141 for AlwaysACK, then all elements of the request will appear in the 2142 response with RESULT TLVs. 2144 Note that if a SET/SET-PROPERTY request with a structure in a 2145 FULLDATA is issued, and some field in the structure is invalid, the 2146 FE will not attempt to indicate which field was invalid, but rather 2147 will indicate that the operation failed. Note further that if there 2148 are multiple errors in a single leaf PATH-DATA/FULLDATA, the FE can 2149 select which error it chooses to return. So if a FULLDATA for a SET/ 2150 SET-PROPERTY of a structure attempts to write one field which is read 2151 only, and attempts to set another field to an invalid value, the FE 2152 can return indication of either error. 2154 A SET/SET-PROPERTY operation on a variable length element with a 2155 length of 0 for the item is not the same as deleting it. If the CE 2156 wishes to delete then the DEL operation should be used whether the 2157 path refers to an array element or an optional structure element. 2159 7.1.1.1.7. Result TLV 2161 The RESULT TLV is an instance of TLV defined in Section 6.2. The 2162 definition is as below: 2164 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 2165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2166 | Type = RESULT | Length | 2167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2168 | Result Value | Reserved | 2169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2171 Figure 19: Result TLV 2172 Defined Result Values 2174 +-----------------------------+-----------+-------------------------+ 2175 | Result Value | Value | Definition | 2176 +-----------------------------+-----------+-------------------------+ 2177 | E_SUCCESS | 0x00 | Success | 2178 | | | | 2179 | E_INVALID_HEADER | 0x01 | Unspecified error with | 2180 | | | header. | 2181 | | | | 2182 | E_LENGTH_MISMATCH | 0x02 | Header length field | 2183 | | | does not match actual | 2184 | | | packet length. | 2185 | | | | 2186 | E_VERSION_MISMATCH | 0x03 | Unresolvable mismatch | 2187 | | | in versions. | 2188 | | | | 2189 | E_INVALID_DESTINATION_PID | 0x04 | Destination PID is | 2190 | | | invalid for the message | 2191 | | | receiver. | 2192 | | | | 2193 | E_LFB_UNKNOWN | 0x05 | LFB Class ID is not | 2194 | | | known by receiver. | 2195 | | | | 2196 | E_LFB_NOT_FOUND | 0x06 | LFB Class ID is known | 2197 | | | by receiver but not | 2198 | | | currently in use. | 2199 | | | | 2200 | E_LFB_INSTANCE_ID_NOT_FOUND | 0x07 | LFB Class ID is known | 2201 | | | but the specified | 2202 | | | instance of that class | 2203 | | | does not exist. | 2204 | | | | 2205 | E_INVALID_PATH | 0x08 | The specified path is | 2206 | | | impossible. | 2207 | | | | 2208 | E_ELEMENT_DOES_NOT_EXIST | 0x09 | The specified path is | 2209 | | | possible but the | 2210 | | | element does not exist | 2211 | | | (e.g., attempt to | 2212 | | | modify a table row that | 2213 | | | has not been created). | 2214 | | | | 2215 | E_EXISTS | 0x0A | The specified object | 2216 | | | exists but it cannot | 2217 | | | exist for the operation | 2218 | | | to succeed (e.g., | 2219 | | | attempt to add an | 2220 | | | existing LFB instance | 2221 | | | or array subscript). | 2222 | | | | 2223 | E_NOT_FOUND | 0x0B | The specified object | 2224 | | | does not exist but it | 2225 | | | must exist for the | 2226 | | | operation to succeed | 2227 | | | (e.g., attempt to | 2228 | | | delete a non-existing | 2229 | | | LFB instance or array | 2230 | | | subscript). | 2231 | | | | 2232 | E_READ_ONLY | 0x0C | Attempt to modify a | 2233 | | | read-only value. | 2234 | | | | 2235 | E_INVALID_ARRAY_CREATION | 0x0D | Attempt to create an | 2236 | | | array with an unallowed | 2237 | | | subscript. | 2238 | | | | 2239 | E_VALUE_OUT_OF_RANGE | 0x0E | Attempt to set a | 2240 | | | parameter to a value | 2241 | | | outside of its | 2242 | | | allowable range. | 2243 | | | | 2244 | E_CONTENTS_TOO_LONG | 0x0D | Attempt to write | 2245 | | | contents larger than | 2246 | | | the target object space | 2247 | | | (i.e., exceeding a | 2248 | | | buffer). | 2249 | | | | 2250 | E_INVALID_PARAMETERS | 0x10 | Any other error with | 2251 | | | data parameters. | 2252 | | | | 2253 | E_INVALID_MESSAGE_TYPE | 0x11 | Message type is not | 2254 | | | acceptable. | 2255 | | | | 2256 | E_INVALID_FLAGS | 0x12 | Message flags are not | 2257 | | | acceptable for the | 2258 | | | given message type. | 2259 | | | | 2260 | E_INVALID_TLV | 0x13 | A TLV is not acceptable | 2261 | | | for the given message | 2262 | | | type. | 2263 | E_EVENT_ERROR | 0x14 | Unspecified error while | 2264 | | | handling an event. | 2265 | | | | 2266 | E_NOT_SUPPORTED | 0x15 | Attempt to perform a | 2267 | | | valid ForCES operation | 2268 | | | that is unsupported by | 2269 | | | the message receiver. | 2270 | | | | 2271 | E_MEMORY_ERROR | 0x16 | A memory error occurred | 2272 | | | while processing a | 2273 | | | message (no error | 2274 | | | detected in the message | 2275 | | | itself) | 2276 | | | | 2277 | E_INTERNAL_ERROR | 0x17 | An unspecified error | 2278 | | | occured while | 2279 | | | processing a message | 2280 | | | (no error detected in | 2281 | | | the message itself) | 2282 | | | | 2283 | - | 0x18-0xFE | Reserved | 2284 | | | | 2285 | E_UNSPECIFIED_ERROR | 0xFF | Unspecified error (for | 2286 | | | when the FE can not | 2287 | | | decide what went wrong) | 2288 +-----------------------------+-----------+-------------------------+ 2290 Table 5 2292 7.1.1.1.8. DATA TLV 2294 A FULLDATA TLV has "T"= FULLDATA and a 16-bit Length followed by the 2295 data value/contents. Likewise, a SPARSEDATA TLV has "T" = 2296 SPARSEDATA, a 16-bit Length, followed by the data value/contents. In 2297 the case of the SPARSEDATA, each element in the Value part of the TLV 2298 will be further encapsulated in an ILV. 2300 Below are the encoding rules for the FULLDATA and SPARSEDATA TLVs. 2301 Appendix C is very useful in illustrating these rules: 2303 1. Both ILVs and TLVs MUST be 32 bit aligned. Any padding bits used 2304 for the alignment MUST be zero on transmission and MUST be 2305 ignored upon reception. 2307 2. FULLDATA TLVs may be used at a particular path only if every 2308 element at that path level is present. In example 1(c) of 2309 Appendix C this concept is illustrated by the presence of all 2310 elements of the structure S in the FULLDATA TLV encoding. This 2311 requirement holds regardless of whether the fields are fixed or 2312 variable length, mandatory or optional. 2314 * If a FULLDATA TLV is used, the encoder MUST lay out data for 2315 each element in the same order in which the data was defined 2316 in the LFB specification. This ensures the decoder is able to 2317 retrieve the data. To use the example 1 again in Appendix C, 2318 this implies the encoder/decoder is assumed to have knowledge 2319 of how structure S is laid out in the definition. 2321 * In the case of a SPARSEDATA, it does not need to be ordered 2322 since the "I" in the ILV uniquely identifies the element. 2323 Examples 1(a) and 1(b) illustrate the power of SPARSEDATA 2324 encoding. 2326 3. Inside a FULLDATA TLV 2328 * The values for atomic, fixed-length fields are given without 2329 any TLV or ILV encapsulation. 2331 * The values for atomic, variable-length fields are given inside 2332 FULLDATA TLVs. 2334 4. Inside a SPARSEDATA TLV 2336 * The values for atomic fields may be given with ILVs (32-bit 2337 index, 32-bit length) 2339 5. Any of the FULLDATA TLVs can contain an ILV but an ILV cannot 2340 contain a FULLDATA. This is because it is hard to disambiguate 2341 ILV since an I is 32 bits and a T is 16 bits. 2343 6. A FULLDATA can also contain a FULLDATA for variable sized 2344 elements. The decoding disambiguation is assumed from rule #3 2345 above. 2347 7.1.1.1.9. SET and GET Relationship 2349 It is expected that a GET-RESPONSE would satisfy the following: 2351 o It would have exactly the same path definitions as those sent in 2352 the GET. The only difference being a GET-RESPONSE will contain 2353 FULLDATA TLVs. 2355 o It should be possible to take the same GET-RESPONSE and convert it 2356 to a SET successfully by merely changing the T in the operational 2357 TLV. 2359 o There are exceptions to this rule: 2361 1. When a KEY selector is used with a path in a GET operation, 2362 that selector is not returned in the GET-RESPONSE; instead the 2363 cooked result is returned. Refer to the examples using KEYS 2364 to see this. 2366 2. When dumping a whole table in a GET, the GET-RESPONSE that 2367 merely edits the T to be SET will end up overwriting the 2368 table. 2370 7.1.2. Protocol Encoding Visualization 2372 The figure below shows a general layout of the PL PDU. A main header 2373 is followed by one or more LFB selections each of which may contain 2374 one or more operation. 2376 main hdr (Config in this case) 2377 | 2378 | 2379 +--- T = LFBselect 2380 | | 2381 | +-- LFBCLASSID 2382 | | 2383 | | 2384 | +-- LFBInstance 2385 | | 2386 | +-- T = SET 2387 | | | 2388 | | +-- // one or more path targets 2389 | | // with their data here to be added 2390 | | 2391 | +-- T = DEL 2392 | . | 2393 | . +-- // one or more path targets to be deleted 2394 | 2395 | 2396 +--- T = LFBselect 2397 | | 2398 | +-- LFBCLASSID 2399 | | 2400 | | 2401 | +-- LFBInstance 2402 | | 2403 | + -- T= SET 2404 | | . 2405 | | . 2406 | + -- T= DEL 2407 | | . 2408 | | . 2409 | | 2410 | + -- T= SET 2411 | | . 2412 | | . 2413 | 2414 | 2415 +--- T = LFBselect 2416 | 2417 +-- LFBCLASSID 2418 | 2419 +-- LFBInstance 2420 . 2421 . 2422 . 2424 Figure 20: PL PDU logical layout 2426 The figure below shows a more detailed example of the general layout 2427 of the operation within a targeted LFB selection. The idea is to 2428 show the different nesting levels a path could take to get to the 2429 target path. 2431 T = SET 2432 | | 2433 | +- T = Path-data 2434 | | 2435 | + -- flags 2436 | + -- IDCount 2437 | + -- IDs 2438 | | 2439 | +- T = Path-data 2440 | | 2441 | + -- flags 2442 | + -- IDCount 2443 | + -- IDs 2444 | | 2445 | +- T = Path-data 2446 | | 2447 | + -- flags 2448 | + -- IDCount 2449 | + -- IDs 2450 | + -- T = KEYINFO 2451 | | + -- KEY_ID 2452 | | + -- KEY_DATA 2453 | | 2454 | + -- T = FULLDATA 2455 | + -- data 2456 | 2457 | 2458 T = SET 2459 | | 2460 | +- T = Path-data 2461 | | | 2462 | | + -- flags 2463 | | + -- IDCount 2464 | | + -- IDs 2465 | | | 2466 | | + -- T = FULLDATA 2467 | | + -- data 2468 | +- T = Path-data 2469 | | 2470 | + -- flags 2471 | + -- IDCount 2472 | + -- IDs 2473 | | 2474 | + -- T = FULLDATA 2475 | + -- data 2476 T = DEL 2477 | 2478 +- T = Path-data 2479 | 2480 + -- flags 2481 + -- IDCount 2482 + -- IDs 2483 | 2484 +- T = Path-data 2485 | 2486 + -- flags 2487 + -- IDCount 2488 + -- IDs 2489 | 2490 +- T = Path-data 2491 | 2492 + -- flags 2493 + -- IDCount 2494 + -- IDs 2495 + -- T = KEYINFO 2496 | + -- KEY_ID 2497 | + -- KEY_DATA 2498 +- T = Path-data 2499 | 2500 + -- flags 2501 + -- IDCount 2502 + -- IDs 2504 Figure 21: Sample operation layout 2506 Appendix D shows a more concise set of use-cases on how the data 2507 encoding is done. 2509 7.2. Core ForCES LFBs 2511 There are two LFBs that are used to control the operation of the 2512 ForCES protocol and to interact with FEs and CEs: 2514 o FE Protocol LFB 2515 o FE Object LFB 2517 Although these LFBs have the same form and interface as other LFBs, 2518 they are special in many respects. They have fixed well-known LFB 2519 Class and Instance IDs. They are statically defined (no dynamic 2520 instantiation allowed) and their status cannot be changed by the 2521 protocol: any operation to change the state of such LFBs (for 2522 instance, in order to disable the LFB) must result in an error. 2523 Moreover, these LFBs must exist before the first ForCES message can 2524 be sent or received. All attributes in these LFBs must have pre- 2525 defined default values. Finally, these LFBs do not have input or 2526 output ports and do not integrate into the intra-FE LFB topology. 2528 7.2.1. FE Protocol LFB 2530 The FE Protocol LFB is a logical entity in each FE that is used to 2531 control the ForCES protocol. The FE Protocol LFB Class ID is 2532 assigned the value 0x1. The FE Protocol LFB Instance ID is assigned 2533 the value 0x1. There MUST be one and only one instance of the FE 2534 Protocol LFB in an FE. The values of the attributes in the FE 2535 Protocol LFB have pre-defined default values that are specified here. 2536 Unless explicit changes are made to these values using Config 2537 messages from the CE, these default values MUST be used for correct 2538 operation of the protocol. 2540 The formal definition of the FE Protocol Object LFB can be found in 2541 Appendix B. 2543 7.2.1.1. FE Protocol capabilities 2545 FE Protocol capabilities are read-only. 2547 7.2.1.1.1. SupportableVersions 2549 ForCES protocol version(s) supported by the FE 2551 7.2.1.1.2. FE Protocol Attributes 2553 FE Protocol attributes (can be read and set). 2555 7.2.1.1.2.1. CurrentRunningVersion 2557 Current running version of the ForCES protocol 2559 7.2.1.1.2.2. FEID 2561 FE unicast ID 2563 7.2.1.1.2.3. MulticastFEIDs 2565 FE multicast ID(s) list - this is a list of multicast IDs that the FE 2566 belongs to. These IDs are configured by the CE. 2568 7.2.1.1.2.4. CEHBPolicy 2570 CE heartbeat policy - This policy, along with the parameter 'CE 2571 Heartbeat Dead Interval (CE HDI)' as described below defines the 2572 operating parameters for the FE to check the CE liveness. The policy 2573 values with meanings are listed as below: 2575 o 0 (default) - This policy specifies that the CE will send a 2576 Heartbeat Message to the FE(s) whenever the CE reaches a time 2577 interval within which no other PL messages were sent from the CE 2578 to the FE(s); refer to Section 4.3.3 and Section 7.9 for details. 2579 The CE HDI attribute as described below is tied to this policy. 2581 o 1 - The CE will not generate any HB messages. This actually means 2582 CE does not want the FE to check the CE liveness. 2584 o Others - reserved. 2586 7.2.1.1.2.5. CEHDI 2588 CE Heartbeat Dead Interval (CE HDI) - The time interval the FE uses 2589 to check the CE liveness. If FE has not received any messages from 2590 CE within this time interval, FE deduces lost connectivity which 2591 implies that the CE is dead or the association to the CE is lost. 2592 Default value 30 s. 2594 7.2.1.1.2.6. FEHBPolicy 2596 FE heartbeat policy - This policy, along with the parameter 'FE 2597 Heartbeat Interval (FE HI)', defines the operating parameters for how 2598 the FE should behave so that the CE can deduce its liveness. The 2599 policy values and the meanings are: 2601 o 0 (default) - The FE should not generate any Heartbeat messages. 2602 In this scenario, the CE is responsible for checking FE liveness 2603 by setting the PL header ACK flag of the message it sends to 2604 AlwaysACK. The FE responds to CE whenever CE sends such Heartbeat 2605 Request Message. Refer to Section 7.9 and Section 4.3.3 for 2606 details. 2608 o 1 - This policy specifies that FE must actively send a Heartbeat 2609 Message if it reaches the time interval assigned by the FE HI as 2610 long as no other messages were sent from FE to CE during that 2611 interval as described in Section 4.3.3. 2613 o Others - Reserved. 2615 7.2.1.1.2.7. FEHI 2617 FE Heartbeat Interval (FE HI) - The time interval the FE should use 2618 to send HB as long as no other messages were sent from FE to CE 2619 during that interval as described in Section 4.3.3. The default 2620 value for an FE HI is 500ms. 2622 7.2.1.1.2.8. CEID 2624 Primary CEID - The CEID that the FE is associated with. 2626 7.2.1.1.2.9. LastCEID 2628 Last Primary CEID - The CEID of the last CE that that the FE 2629 associated with. This CE ID is reported to the new Primary CEID. 2631 7.2.1.1.2.10. BackupCEs 2633 The list of backup CEs an FE can use as backups. Refer to Section 8 2634 for details. 2636 7.2.1.1.2.11. CEFailoverPolicy 2638 CE failover policy - This specifies the behavior of the FE when the 2639 association with the CE is lost. There is a very tight relation 2640 between CE failover policy and Section 7.2.1.1.2.8, 2641 Section 7.2.1.1.2.10, Section 7.2.1.1.2.12, and Section 8. When an 2642 association is lost, depending on configuration, one of the policies 2643 listed below is activated. 2645 o 0 (default) - FE should stop functioning immediately and 2646 transition to FE DOWN. 2648 o 1 - The FE should continue running and do what it can even without 2649 an associated CE. This basically requires that the FE support CE 2650 Graceful restart (and defines such support in its capabilities). 2651 If the CEFTI expires before the FE re-associates with either the 2652 primary (Section 7.2.1.1.2.8) or one of possibly several backup 2653 CEs (Section 7.2.1.1.2.10), the FE will go operationally down. 2655 o Others - Reserved 2657 7.2.1.1.2.12. CEFTI 2659 CE Failover Timeout Interval (CEFTI) - The time interval associated 2660 with the CE failover policy case '0' and '2'. The default value is 2661 set to 300 seconds. Note that it is advisable to set the CEFTI value 2662 much higher than the CE Heartbeat Dead Interval (CE HDI) since the 2663 effect of expiring this parameter is devastating to the operation of 2664 the FE. 2666 7.2.1.1.2.13. FERestartPolicy 2668 FE restart policy - This specifies the behavior of the FE during an 2669 FE restart. The restart may be from an FE failure or other reasons 2670 that have made FE down and then need to restart. The values are 2671 defined as below: 2673 o 0(default)- Restart the FE from scratch. In this case, the FE 2674 should start from the pre-association phase. 2676 o others - Reserved for future use. 2678 7.2.2. FE Object LFB 2680 The FE Object LFB is a logical entity in each FE and contains 2681 attributes relative to the FE itself, and not to the operation of the 2682 ForCES protocol. 2684 The formal definition of the FE Object LFB can be found in 2685 [FE-MODEL]. The model captures the high level properties of the FE 2686 that the CE needs to know to begin working with the FE. The class ID 2687 for this LFB Class is also assigned in [FE-MODEL]. The singular 2688 instance of this class will always exist, and will always have 2689 instance ID 0x1 within its class. It is common, although not 2690 mandatory, for a CE to fetch much of the attribute and capability 2691 information from this LFB instance when the CE begins controlling the 2692 operation of the FE. 2694 7.3. Semantics of Message Direction 2696 Recall: The PL provides a master(CE)-Slave(FE) relationship. The 2697 LFBs reside at the FE and are controlled by CE. 2699 When messages go from the CE, the LFB Selector (Class and instance) 2700 refers to the destination LFB selection which resides in the FE. 2702 When messages go from the FE to the CE, the LFB Selector (Class and 2703 instance) refers to the source LFB selection which resides in the FE. 2705 7.4. Association Messages 2707 The ForCES Association messages are used to establish and teardown 2708 associations between FEs and CEs. 2710 7.4.1. Association Setup Message 2712 This message is sent by the FE to the CE to setup a ForCES 2713 association between them. 2715 Message transfer direction: 2716 FE to CE 2718 Message header: 2719 The Message Type in the header is set MessageType= 2720 'AssociationSetup'. The ACK flag in the header MUST be ignored, 2721 and the association setup message always expects to get a response 2722 from the message receiver (CE), whether the setup is successful or 2723 not. The correlator field in the header is set, so that FE can 2724 correlate the response coming back from the CE correctly. The FE 2725 may set the source ID to 0 in the header to request that the CE 2726 should assign an FE ID for the FE in the setup response message. 2728 Message body: 2729 The association setup message body optionally consists of zero, 2730 one or two LFBselect TLVs, as described in Section 7.1.1.1.5. The 2731 Association Setup message only operates on the FE Object and FE 2732 Protocol LFBs, therefore, the LFB class ID in the LFBselect TLV 2733 only points to these two kinds of LFBs. 2735 The OPERSELECT in the LFBselect TLV is defined as a 'REPORT' 2736 operation. More than one attribute may be announced in this 2737 message using REPORT operation to let the FE declare its 2738 configuration parameters in an unsolicited manner. These may 2739 contain attributes suggesting values such as the FE HB Interval, 2740 or the FEID. The OPERSELECT used is defined below. 2742 OPERSELECT for Association Setup: 2744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2745 | Type = REPORT | Length | 2746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2747 | PATH-DATA-TLV for REPORT | 2748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2749 Figure 22: OPERSELECT 2751 Type: 2752 Only one operation type is defined for the association setup 2753 message: 2755 Type = "REPORT" - this type of operation is for FE to 2756 report something to CE. 2758 PATH-DATA-TLV for REPORT: 2759 This is generically a PATH-DATA-TLV format that has been defined 2760 in "Protocol Grammar" section (Section 7.1) in the PATH-DATA BNF 2761 definition. The PATH-DATA-TLV for REPORT operation MAY contain 2762 FULLDATA-TLV(s) but SHALL NOT contain any RESULT-TLV in the data 2763 format. The RESULT-TLV is defined in Section 7.1.1.1.7 and the 2764 FULLDATA-TLV is defined in Section 7.1.1.1.8. 2766 To better illustrate the above PDU format, a tree structure for the 2767 format is shown below: 2769 main hdr (type = Association Setup) 2770 | 2771 | 2772 +--- T = LFBselect 2773 | | 2774 | +-- LFBCLASSID = FE object 2775 | | 2776 | | 2777 | +-- LFBInstance = 0x1 2778 | 2779 +--- T = LFBselect 2780 | 2781 +-- LFBCLASSID = FE Protocol object 2782 | 2783 | 2784 +-- LFBInstance = 0x1 2785 | 2786 +---OPERSELECT = REPORT 2787 | 2788 +-- Path-data to one or more attributes 2790 Figure 23: PDU Format For Association Setup 2792 7.4.2. Association Setup Response Message 2794 This message is sent by the CE to the FE in response to the Setup 2795 message. It indicates to the FE whether the setup is successful or 2796 not, i.e., whether an association is established. 2798 Message transfer direction: 2799 CE to FE 2801 Message Header: 2802 The Message Type in the header is set MessageType= 2803 'AssociationSetupResponse'. The ACK flag in the header MUST be 2804 ignored, and the setup response message never expects to get any 2805 more responses from the message receiver (FE). The destination 2806 ID in the header will be set to the source ID in the 2807 corresponding association setup message, unless that source ID 2808 was 0. If the corresponding source ID was 0, then the CE will 2809 assign an FE ID value and use that value for the destination ID. 2811 Message body: 2812 The Association Setup Response message body only consists of one 2813 TLV, the Association Result TLV, the format of which is as 2814 follows: 2816 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 2817 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2818 | Type = ASRresult | Length | 2819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2820 | Association Setup Result | 2821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2823 Figure 24: ASResult OPERSELECT 2825 Type (16 bits): 2826 The type of the TLV is "ASResult". 2828 Length (16 bits): 2829 Length of the TLV including the T and L fields, in octets. 2831 Association Setup Result (32 bits): 2832 This indicates whether the setup msg was successful or whether 2833 the FE request was rejected by the CE. the defined values are: 2835 0 = success 2836 1 = FE ID invalid 2838 2 = permission denied 2840 7.4.3. Association Teardown Message 2842 This message can be sent by the FE or CE to any ForCES element to end 2843 its ForCES association with that element. 2845 Message transfer direction: 2846 CE to FE, or FE to CE (or CE to CE) 2848 Message Header: 2849 The Message Type in the header is set MessageType= 2850 "AssociationTeardown". The ACK flag MUST be ignored. The 2851 correlator field in the header MUST be set to zero and MUST be 2852 ignored by the receiver. 2854 Message Body: 2855 The association teardown message body only consists of one TLV, 2856 the Association Teardown Reason TLV, the format of which is as 2857 follows: 2859 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 2860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2861 | Type = ASTreason | Length | 2862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2863 | Teardown Reason | 2864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2866 Figure 25: ASTreason TLV 2868 Type (16 bits): 2869 The type of the TLV is "ASTreason". 2871 Length (16 bits): 2872 Length of the TLV including the T and L fields, in octets. 2874 Teardown Reason (32 bits): 2875 This indicates the reason why the association is being 2876 terminated. Several reason codes are defined as follows. 2878 0 - normal teardown by administrator 2879 1 - error - loss of heartbeats 2881 2 - error - out of bandwidth 2883 3 - error - out of memory 2885 4 - error - application crash 2887 255 - error - other or unspecified 2889 7.5. Configuration Messages 2891 The ForCES Configuration messages are used by CE to configure the FEs 2892 in a ForCES NE and report the results back to the CE. 2894 7.5.1. Config Message 2896 This message is sent by the CE to the FE to configure LFB attributes 2897 in the FE. This message is also used by the CE to subscribe/ 2898 unsubscribe to LFB events. 2900 As usual, a config message is composed of a common header followed by 2901 a message body that consists of one or more TLV data format. 2902 Detailed description of the message is as below. 2904 Message transfer direction: 2905 CE to FE 2907 Message Header: 2908 The Message Type in the header is set MessageType= 'Config'. The 2909 ACK flag in the header can be set to any value defined in 2910 Section 6.1, to indicate whether or not a response from FE is 2911 expected by the message. 2913 Message body: 2914 The config message body MUST consist of at least one LFBselect 2915 TLV as described in Section 7.1.1.1.5. The OPERSELECT in the 2916 LFBselect TLV is defined below. 2918 OPERSELECT for Config: 2920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2921 | Type | Length | 2922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2923 | PATH-DATA-TLV | 2924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2925 Figure 26: OPERSELECT for Config 2927 Type: 2928 The operation type for config message. two types of operations 2929 for the config message are defined: 2931 Type = "SET" - this operation is to set LFB attributes 2933 Type = "SET-PROPERTY" - this operation is to set LFB 2934 attribute properties 2936 Type = "DEL" - this operation to delete some LFB 2937 attributes 2939 Type = "COMMIT" - this operation is sent to the FE to 2940 commit in a 2pc transaction. A COMMIT TLV is an empty TLV 2941 i.e it has no "V"alue. In other words, There is a Length 2942 of 4 (which is for the header only). 2944 PATH-DATA-TLV: 2945 This is generically a PATH-DATA-TLV format that has been defined 2946 in "Protocol Grammar" section (Section 7.1) in the PATH-DATA BNF 2947 definition. The restriction on the use of PATH-DATA-TLV for SET/ 2948 SET-PROPERTY operation is that it MUST contain either a FULLDATA 2949 or SPARSEDATA TLV(s), but MUST NOT contain any RESULT-TLV. The 2950 restriction on the use of PATH-DATA-TLV for DEL operation is it 2951 MAY contain FULLDATA or SPARSEDATA TLV(s), but MUST NOT contain 2952 any RESULT-TLV. The RESULT-TLV is defined in Section 7.1.1.1.7 2953 and FULLDATA and SPARSEDATA TLVs is defined in Section 7.1.1.1.8. 2955 *Note: For Event subscription, the events will be defined by the 2956 individual LFBs. 2958 To better illustrate the above PDU format, a tree structure for the 2959 format is shown below: 2961 main hdr (type = Config) 2962 | 2963 | 2964 +--- T = LFBselect 2965 . | 2966 . +-- LFBCLASSID = target LFB class 2967 . | 2968 | 2969 +-- LFBInstance = target LFB instance 2970 | 2971 | 2972 +-- T = operation { SET } 2973 | | 2974 | +-- // one or more path targets 2975 | // associated with FULL or SPARSEDATA TLV(s) 2976 | 2977 +-- T = operation { DEL } 2978 | | 2979 | +-- // one or more path targets 2981 Figure 27: PDU Format for Config 2983 7.5.2. Config Response Message 2985 This message is sent by the FE to the CE in response to the Config 2986 message. It indicates whether the Config was successful or not on 2987 the FE and also gives a detailed response regarding the configuration 2988 result of each attribute. 2990 Message transfer direction: 2991 FE to CE 2993 Message Header: 2994 The Message Type in the header is set MessageType= 'Config 2995 Response'. The ACK flag in the header is always ignored, and the 2996 Config Response message never expects to get any further response 2997 from the message receiver (CE). 2999 Message body: 3000 The Config message body MUST consist of at least one LFBselect 3001 TLV as described in Section 7.1.1.1.5. The OPERSELECT in the 3002 LFBselect TLV is defined below. 3004 OPERSELECT for Config Response: 3006 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3007 | Type | Length | 3008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3009 | PATH-DATA-TLV | 3010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3012 Figure 28: OPERSELECT for Config Response 3014 Type: 3015 The operation type for Config Response message. Two types of 3016 operations for the Config Response message are defined: 3018 Type = "SET-RESPONSE" - this operation is for the response 3019 of SET operation of LFB attributes 3021 Type = "SET-PROPERTY-RESPONSE" - this operation is for the 3022 response of SET-PROPERTY operation of LFB attribute 3023 properties 3025 Type = "DEL-RESPONSE" - this operation is for the response 3026 of the DELETE operation of LFB attributes 3028 Type = "COMMIT-RESPONSE" - this operation is sent to the 3029 CE to confirm a commit success in a 2pc transaction. A 3030 COMMIT-RESPONSE TLV is an empty TLV i.e., it has no 3031 "V"alue. In other words, there is a length of 4 (which is 3032 for the header only). 3034 PATH-DATA-TLV: 3035 This is generically a PATH-DATA-TLV format that has been defined 3036 in "Protocol Grammar" section (Section 7.1) in the PATH-DATA BNF 3037 definition. The restriction on the use of PATH-DATA-TLV for SET- 3038 RESPONSE operation is that it MUST contain RESULT-TLV(s). The 3039 restriction on the use of PATH-DATA-TLV for DEL-RESPONSE 3040 operation is it also MUST contain RESULT-TLV(s). The RESULT-TLV 3041 is defined in Section 7.1.1.1.7. 3043 7.6. Query Messages 3045 The ForCES query messages are used by the CE to query LFBs in the FE 3046 for informations like LFB attributes, capabilities, statistics, etc. 3047 Query Messages include the Query Message and the Query Response 3048 Message. 3050 7.6.1. Query Message 3052 A Query message is composed of a common header and a message body 3053 that consists of one or more TLV data format. Detailed description 3054 of the message is as below. 3056 Message transfer direction: 3057 from CE to FE 3059 Message Header: 3060 The Message Type in the header is set to MessageType= 'Query'. 3061 The ACK flag in the header is always ignored, and a full response 3062 for a query message is always expected. The Correlator field in 3063 the header is set, so that the CE can locate the response back 3064 from FE correctly. 3066 Message body: 3067 The query message body MUST consist of at least one LFBselect TLV 3068 as described in Section 7.1.1.1.5. The OPERSELECT in the 3069 LFBselect TLV is defined below. 3071 OPERSELECT for Query: 3073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3074 | Type = GET/GET-PROPERTY | Length | 3075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3076 | PATH-DATA-TLV for GET/GET-PROPERTY | 3077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3079 Figure 29: TLV for Query 3081 Type: 3082 The operation type for query. Two operation types are defined: 3084 Type = "GET" - this operation is to request to get LFB 3085 attributes. 3087 Type = "GET-PROPERTY" - this operation is to request to 3088 get LFB attributes. 3090 PATH-DATA-TLV for GET/GET-PROPERTY: 3091 This is generically a PATH-DATA-TLV format that has been defined 3092 in "Protocol Grammar" section (Section 7.1) in the PATH-DATA BNF 3093 definition. The restriction on the use of PATH-DATA-TLV for GET/ 3094 GET-PROPERTY operation is it MUST NOT contain any SPARSEDATA or 3095 FULLDATA TLV and RESULT-TLV in the data format. 3097 To better illustrate the above PDU format, a tree structure for the 3098 format is shown below: 3100 main hdr (type = Query) 3101 | 3102 | 3103 +--- T = LFBselect 3104 . | 3105 . +-- LFBCLASSID = target LFB class 3106 . | 3107 | 3108 +-- LFBInstance = target LFB instance 3109 | 3110 | 3111 +-- T = operation { GET } 3112 | | 3113 | +-- // one or more path targets 3114 | 3115 +-- T = operation { GET } 3116 . | 3117 . +-- // one or more path targets 3118 . 3120 Figure 30: PDU Format 3122 7.6.2. Query Response Message 3124 When receiving a Query message, the receiver should process the 3125 message and come up with a query result. The receiver sends the 3126 query result back to the message sender by use of the Query Response 3127 Message. The query result can be the information being queried if 3128 the query operation is successful, or can also be error codes if the 3129 query operation fails, indicating the reasons for the failure. 3131 A Query Response message is also composed of a common header and a 3132 message body consisting of one or more TLVs describing the query 3133 result. Detailed description of the message is as below. 3135 Message transfer direction: 3136 from FE to CE 3138 Message Header: 3139 The Message Type in the header is set to MessageType= 3140 'QueryResponse'. The ACK flag in the header is ignored. As a 3141 response itself, the message does not expect a further response. 3143 Message body: 3144 The Query Response message body MUST consist of at least one 3145 LFBselect TLV as described in Section 7.1.1.1.5. The OPERSELECT 3146 in the LFB select TLV is defined below. 3148 OPERSELECT for Query Response: 3150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3151 |Type = GET-RESPONSE/GET-PROPERTY-RESPONSE| Length | 3152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3153 | PATH-DATA-TLV for GET-RESPONSE/GET-PROPERTY-RESPONSE | 3154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3156 Figure 31: TLV for Query Response 3158 Type: 3159 The operation type for query response. One operation type is 3160 defined: 3162 Type = "GET-RESPONSE" - this operation is to response to 3163 get operation of LFB attributes. 3165 Type = "GET-PROPERTY-RESPONSE" - this operation is to 3166 response to GET-PROPERTY operation of LFB attributes. 3168 PATH-DATA-TLV for GET-RESPONSE/GET-PROPERTY-RESPONSE: 3169 This is generically a PATH-DATA-TLV format that has been defined 3170 in "Protocol Grammar" section (Section 7.1) in the PATH-DATA BNF 3171 definition. The PATH-DATA-TLV for GET-RESPONSE operation MAY 3172 contain SPARSEDATA TLV, FULLDATA TLV and/or RESULT-TLV(s) in the 3173 data encoding. The RESULT-TLV is defined in Section 7.1.1.1.7 3174 and the SPARSEDATA and FULLDATA TLVs are defined in 3175 Section 7.1.1.1.8. 3177 7.7. Event Notification Message 3179 Event Notification Message is used by FE to asynchronously notify CE 3180 of events that happen in the FE. 3182 All events that can be generated in an FE are subscribable by the CE. 3183 The CE can subscribe to an event via a Config message with SET- 3184 PROPERTY operation, where the included path specifies the event, as 3185 defined by the LFB Library and described by the FE Model. 3187 As usual, an Event Notification Message is composed of a common 3188 header and a message body that consists of one or more TLV data 3189 format. Detailed description of the message is as below. 3191 Message Transfer Direction: 3192 FE to CE 3194 Message Header: 3195 The Message Type in the message header is set to 3196 MessageType = 'EventNotification'. The ACK flag in the header 3197 MUST be ignored by the CE, and the event notification message does 3198 not expect any response from the receiver. 3200 Message Body: 3201 The event notification message body MUST consist of at least one 3202 LFBselect TLV as described in Section 7.1.1.1.5. The OPERSELECT 3203 in the LFBselect TLV is defined below. 3205 OPERSELECT for Event Notification: 3207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3208 | Type = REPORT | Length | 3209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3210 | PATH-DATA-TLV for REPORT | 3211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3213 Figure 32: TLV for Event Notification 3215 Type: 3216 Only one operation type is defined for the event notification 3217 message: 3219 Type = "REPORT" - this type of operation is for FE to 3220 report something to CE. 3222 PATH-DATA-TLV for REPORT: 3223 This is generically a PATH-DATA-TLV format that has been defined 3224 in "Protocol Grammar" section (Section 7.1) in the PATH-DATA BNF 3225 definition. The PATH-DATA-TLV for REPORT operation MAY contain 3226 FULLDATA or SPARSEDATA TLV(s) but MUST NOT contain any RESULT-TLV 3227 in the data format. 3229 To better illustrate the above PDU format, a tree structure for the 3230 format is shown below: 3232 main hdr (type = Event Notification) 3233 | 3234 | 3235 +--- T = LFBselect 3236 | 3237 +-- LFBCLASSID = target LFB class 3238 | 3239 | 3240 +-- LFBInstance = target LFB instance 3241 | 3242 | 3243 +-- T = operation { REPORT } 3244 | | 3245 | +-- // one or more path targets 3246 | // associated with FULL/SPARSE DATA TLV(s) 3247 +-- T = operation { REPORT } 3248 . | 3249 . +-- // one or more path targets 3250 . // associated with FULL/SPARSE DATA TLV(s) 3252 Figure 33: PDU Format 3254 7.8. Packet Redirect Message 3256 A packet Redirect message is used to transfer data packets between CE 3257 and FE. Usually these data packets are control packets but they may 3258 be just data-path packets which need further (exception or high- 3259 touch) processing. It is also feasible that this message carries no 3260 data packets and rather just metadata. 3262 The Packet Redirect message data format is formated as follows: 3264 Message Direction: 3265 CE to FE or FE to CE 3267 Message Header: 3268 The Message Type in the header is set to MessageType= 3269 'PacketRedirect'. 3271 Message Body: 3272 This consists of one or more TLVs that contain or describe the 3273 packet being redirected. The TLV is specifically a Redirect TLV 3274 (with the TLV Type="Redirect"). Detailed data format of a 3275 Redirect TLV for packet redirect message is as below: 3277 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 3278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3279 | Type = Redirect | Length | 3280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3281 | Meta Data TLV | 3282 . . 3283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3284 | Redirect Data TLV | 3285 . . 3286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3288 Figure 34: Redirect_Data TLV 3290 Meta Data TLV: 3291 This is a TLV that specifies meta-data associated with followed 3292 redirected data. The TLV is as follows: 3294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3295 | Type = METADATA | Length | 3296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3297 | Meta Data ILV | 3298 . . 3299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3300 ~ ... ~ 3301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3302 | Meta Data ILV | 3303 . . 3304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3306 Figure 35: METADARA TLV 3308 Meta Data ILV: 3309 This is an Identifier-Length-Value format that is used to describe 3310 one meta data. The ILV has the format as: 3312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3313 | Meta Data ID | 3314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3315 | Length | 3316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3317 | Meta Data Value | 3318 . . 3319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3321 Figure 36: Meta Data ILV 3323 Where, Meta Data ID is an identifier for the meta data, which is 3324 statically assigned by the LFB definition. 3326 Redirect Data TLV 3327 This is a TLV describing one packet of data to be directed via the 3328 redirect operation. The TLV format is as follows: 3330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3331 | Type = REDIRECTDATA | Length | 3332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3333 | Redirected Data | 3334 . . 3335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3337 Figure 37: Redirect Data TLV 3339 Redirected Data: 3340 This field contains the packet that is to be redirected in network 3341 byte order. The packet should be 32-bits aligned as is the dat 3342 for all TLVs. The metadata infers what kind of packet is carried 3343 in value field and therefore allows for easy decoding of data 3344 encapsulated 3346 7.9. Heartbeat Message 3348 The Heartbeat (HB) Message is used for one ForCES element (FE or CE) 3349 to asynchronously notify one or more other ForCES elements in the 3350 same ForCES NE on its liveness. Section 4.3.3 describes the traffic- 3351 sensitive approach used. 3353 A Heartbeat Message is sent by a ForCES element periodically. The 3354 parameterization and policy definition for heartbeats for an FE is 3355 managed as attributes of the FE Protocol Object LFB, and can be set 3356 by CE via a Config message. The Heartbeat message is a little 3357 different from other protocol messages in that it is only composed of 3358 a common header, with the message body left empty. A detailed 3359 description of the message is as below. 3361 Message Transfer Direction: 3362 FE to CE or CE to FE 3364 Message Header: 3365 The Message Type in the message header is set to MessageType = 3366 'Heartbeat'. Section 4.3.3 describes the HB mechanisms used. 3367 The ACK flag in the header MUST be set to either 'NoACK' or 3368 'AlwaysACK' when the HB is sent. 3370 * When set to 'NoACK', the HB is not soliciting for a response. 3372 * When set to 'AlwaysACK', the HB Message sender is always 3373 expecting a response from its receiver. According the HB 3374 policies defined in Section 7.2.1, only the CE can send such 3375 an HB message to query FE liveness. For simplicity and 3376 because of the minimal nature of the HB message, the response 3377 to a HB message is another HB message, i.e., no specific HB 3378 response message is defined. Whenever an FE receives a HB 3379 message marked with 'AlwaysACK' from the CE, the FE MUST send 3380 a HB message back immediately. The HB message sent by the FE 3381 in response to the 'AlwasyACK' MUST modify the source and 3382 destination IDs so that the ID of the FE is the source ID and 3383 the CE ID of the sender is the destination ID, and MUST 3384 change the ACK information to 'NoACK'. A CE MUST NOT respond 3385 to an HB message with 'AlwasyACK' set. 3387 * When set to anything else other than 'NoACK' or 'AlwaysACK', 3388 the HB Message is treated as if it was a 'NoACK'. 3390 The correlator field in the HB message header SHOULD be set 3391 accordingly when a response is expected so that a receiver can 3392 correlate the response correctly. The correlator field MAY be 3393 ignored if no response is expected. 3395 Message Body: 3396 The message body is empty for the Heartbeat Message. 3398 8. High Availability Support 3400 The ForCES protocol provides mechanisms for CE redundancy and 3401 failover, in order to support High Availability as defined in 3402 [RFC3654]. FE redundancy and FE to FE interaction is currently out 3403 of scope of this document. There can be multiple redundant CEs and 3404 FEs in a ForCES NE. However, at any one time only one primary CE can 3405 control the FEs though there can be multiple secondary CEs. The FE 3406 and the CE PL are aware of the primary and secondary CEs. This 3407 information (primary, secondary CEs) is configured in the FE and in 3408 the CE PLs during pre-association by the FEM and the CEM 3409 respectively. Only the primary CE sends control messages to the FEs. 3411 8.1. Relation with the FE Protocol 3413 High Availability parameterization in an FE is driven by configuring 3414 the FE Protocol Object LFB (refer to Appendix B and Section 7.2.1). 3415 The FE Heartbeat Interval, CE Heartbeat Dead Interval, and CE 3416 Heartbeat policy help in detecting connectivity problems between an 3417 FE and CE. The CE Failover policy defines the reaction on a detected 3418 failure. 3420 Figure 38 extends the state machine illustrated in Figure 4 to allow 3421 for new states that facilitate connection recovery. 3423 +-----------------+ 3424 Lost association && | Pre-Association | 3425 CE failover policy = 0 | (Association | 3426 +------------>-->--| in +<----+ 3427 | | progress) | | 3428 | +--------+--------+ | 3429 | | | 3430 | Y | 3431 | | | 3432 | Associated ^ 3433 | | | 3434 | Y | 3435 | | | 3436 | +-------+-------+ | 3437 | CE issues | DOWN FE | | 3438 | FEO Admin | (ForCES | ^ 3439 | UP | Active) | | 3440 | +-------- | | | 3441 | | | | | 3442 | | +---------------+ ^ 3443 | Y ^ | 3444 | | | |CEFTI expired 3445 | Y |CE issues Admin | && 3446 | | | DOWN |!connected 3447 | | | ^ 3448 | Y | | 3449 +-+-----------+ | +------+------+ 3450 | UP |------------+ |Disconnected | 3451 |(associated) | | | 3452 | |Lost association | | 3453 | | && | | 3454 | |--------->------>----->|(Continue | 3455 | |CE failover policy |Forwarding) | 3456 | | = 1 | | 3457 +-------------+ +-------------+ 3458 ^ | 3459 | Resynchronize !CEFTI expired | 3460 | complete && | 3461 | reconnected | 3462 | +---------------+ | 3463 | | Resynch state | | 3464 | | (via | | 3465 +-----------| graceful |<--------+ 3466 | restart) | 3467 +---------------+ 3469 Figure 38: FE State Machine considering HA 3471 Section 4.2 describes transitions between the UP, DOWN and Pre- 3472 association states. In this section we deal with disconnected 3473 states. 3475 During a communication failure between the FE and CE (which is caused 3476 due to CE or link reasons, i.e. not FE related), either the TML on 3477 the FE will trigger the FE PL regarding this failure or it will be 3478 detected using the HB messages between FEs and CEs. The 3479 communication failure, regardless of how it is detected, MUST be 3480 considered as a loss of association between the CE and corresponding 3481 FE. 3483 If the FE's FEPO CE Failover Policy is configured to mode 0 (the 3484 default), it will immediately transition to the pre-association 3485 phase. This means that if it ever reconnects again, it will re- 3486 establish state from scratch. 3488 If the FE's FEPO CE Failover Policy is configured to mode 1, it 3489 implies that the FE is capable of HA as well as graceful restart 3490 recovery. In such a case, the FE transitions to the disconnected 3491 state and the CEFTI timer is started. The FE continues to forward 3492 packets during this state. It also recycles through its configured 3493 secondary CEs in a round-robin fashion. It first adds its primary CE 3494 to the tail of backup CEs and sets its primary CE to be the first 3495 secondary. It then attempts to connect to associate with the new 3496 primary CE. If it fails to re-associate with any CE and the CEFTI 3497 expires, the FE transitions to the Pre-association state. 3499 If the FE, while in the Disconnected state, manages to reconnect to a 3500 new primary CE before CEFTI expires it transitions to the Resynch 3501 state. In the Resynch state, the FE tries to recover any state that 3502 may have been lost during the Disonnected state. Graceful restart is 3503 one such mechanism. How the FE achieves these goals is out of scope 3504 for this document. 3506 Figure 39 below illustrates the Forces message sequences that the FE 3507 uses to recover the connection. 3509 FE CE Primary CE Secondary 3510 | | | 3511 | Asso Estb,Caps exchg | | 3512 1 |<--------------------->| | 3513 | | | 3514 | All msgs | | 3515 2 |<--------------------->| | 3516 | | | 3517 | | | 3518 | FAILURE | 3519 | | 3520 | Asso Estb,Caps exchange | 3521 3 |<------------------------------------------>| 3522 | | 3523 | Event Report (pri CE down) | 3524 4 |------------------------------------------->| 3525 | | 3526 | All Msgs | 3527 5 |<------------------------------------------>| 3529 Figure 39: CE Failover for Report Primary Mode 3531 A CE-to-CE synchronization protocol would be needed to support fast 3532 failover as well as to address some of the corner cases, however this 3533 will not be defined by the ForCES protocol as it is out of scope for 3534 this specification. 3536 An explicit message (a Config message setting Primary CE attribute in 3537 ForCES Protocol object) from the primary CE, can also be used to 3538 change the Primary CE for an FE during normal protocol operation. 3540 Also note that the FEs in a ForCES NE could also use a multicast CE 3541 ID, i.e., they could be associated with a group of CEs (this assumes 3542 the use of a CE-CE synchronization protocol, which is out of scope 3543 for this specification). In this case, the loss of association would 3544 mean that communication with the entire multicast group of CEs has 3545 been lost. The mechanisms described above will apply for this case 3546 as well during the loss of association. If, however, the secondary 3547 CE was also using the multicast CE ID that was lost, then the FE will 3548 need to form a new association using a different CE ID. If the 3549 capability exists, the FE MAY first attempt to form a new association 3550 with original primary CE using a different non multicast CE ID. 3552 8.2. Responsibilities for HA 3554 TML Level: 3556 1. The TML controls logical connection availability and failover. 3558 2. The TML also controls peer HA management. 3560 At this level, control of all lower layers, for example transport 3561 level (such as IP addresses, MAC addresses etc) and associated links 3562 going down are the role of the TML. 3564 PL Level: 3565 All other functionality, including configuring the HA behavior during 3566 setup, the CE IDs used to identify primary and secondary CEs, 3567 protocol messages used to report CE failure (Event Report), Heartbeat 3568 messages used to detect association failure, messages to change the 3569 primary CE (Config), and other HA related operations described 3570 before, are the PL responsibility. 3572 To put the two together, if a path to a primary CE is down, the TML 3573 would take care of failing over to a backup path, if one is 3574 available. If the CE is totally unreachable then the PL would be 3575 informed and it would take the appropriate actions described before. 3577 9. Security Considerations 3579 ForCES architecture identifies several levels of security in 3580 [RFC3746]. ForCES PL uses security services provided by the ForCES 3581 TML. The TML provides security services such as endpoint 3582 authentication service, message authentication service and 3583 confidentiality service. Endpoint authentication service is invoked 3584 at the time of the pre-association connection establishment phase and 3585 message authentication is performed whenever the FE or CE receives a 3586 packet from its peer. 3588 The following are the general security mechanisms that need to be in 3589 place for ForCES PL. 3591 o Security mechanisms are session controlled - that is, once the 3592 security is turned on depending upon the chosen security level (No 3593 Security, Authentication, Confidentiality), it will be in effect 3594 for the entire duration of the session. 3596 o An operator should configure the same security policies for both 3597 primary and backup FEs and CEs (if available). This will ensure 3598 uniform operations and avoid unnecessary complexity in policy 3599 configuration. 3601 9.1. No Security 3603 When "No security" is chosen for ForCES protocol communication, both 3604 endpoint authentication and message authentication service needs to 3605 be performed by ForCES PL. Both these mechanism are weak and do not 3606 involve cryptographic operation. An operator can choose "No 3607 Security" level when the ForCES protocol endpoints are within a 3608 single box, for example. 3610 In order to have interoperable and uniform implementation across 3611 various security levels, each CE and FE endpoint MUST implement this 3612 level. 3614 9.1.1. Endpoint Authentication 3616 Each CE and FE PL maintains a list of associations as part its of 3617 configuration. This is done via the CEM and FEM interfaces. An FE 3618 MUST connect to only those CEs that are configured via the FEM; 3619 similarly, a CE should accept the connection and establish 3620 associations for the FEs which are configured via the CEM. The CE 3621 should validate the FE identifier before accepting the connections 3622 during the pre-association phase. 3624 9.1.2. Message authentication 3626 When a CE or FE initiates a message, the receiving endpoint MUST 3627 validate the initiator of the message by checking the common header 3628 CE or FE identifiers. This will ensure proper protocol functioning. 3629 This extra processing step is recommend even when underlying provides 3630 TLM layer security services exist. 3632 9.2. ForCES PL and TML security service 3634 This section is applicable if an operator wishes to use the TML 3635 security services. A ForCES TML MUST support one or more security 3636 services such as endpoint authentication service, message 3637 authentication service, and confidentiality service, as part of TML 3638 security layer functions. It is the responsibility of the operator 3639 to select an appropriate security service and configure security 3640 policies accordingly. The details of such configuration are outside 3641 the scope of the ForCES PL and are dependent on the type of transport 3642 protocol and the nature of the connection. 3644 All these configurations should be done prior to starting the CE and 3645 FE. 3647 When certificates-based authentication is being used at the TML, the 3648 certificate can use a ForCES-specific naming structure as certificate 3649 names and, accordingly, the security policies can be configured at 3650 the CE and FE. 3652 9.2.1. Endpoint authentication service 3654 When TML security services are enabled, the ForCES TML performs 3655 endpoint authentication. Security association is established between 3656 CE and FE and is transparent to the ForCES PL. 3658 9.2.2. Message authentication service 3660 This is a TML specific operation and is transparent to the ForCES PL. 3661 For details, refer to Section 5. 3663 9.2.3. Confidentiality service 3665 This is a TML specific operation and is transparent to the ForCES PL. 3666 For details, refer to Section 5. 3668 10. Acknowledgments 3670 The authors of this draft would like to acknowledge and thank the 3671 ForCES Working Group and especially the following: Furquan Ansari, 3672 Alex Audu, Steven Blake, Shuchi Chawla, Alan DeKok, Ellen M. 3673 Deleganes, Xiaoyi Guo, Yunfei Guo, Evangelos Haleplidis, Joel M. 3674 Halpern (who should probably be listed among the authors), Zsolt 3675 Haraszti, Fenggen Jia, John C. Lin, Alistair Munro, Jeff Pickering, 3676 T. Sridhlar, Guangming Wang, Chaoping Wu, and Lily L. Yang, for their 3677 contributions. We would also like to thank David Putzolu, and 3678 Patrick Droz for their comments and suggestions on the protocol and 3679 for their infinite patience. We would also like to thank Sue Hares 3680 and Alia Atlas for extensive reviews of the document. 3682 Alia Atlas has done a wonderful job of shaping the draft to make it 3683 more readable by providing the IESG feedback. 3685 The editors have used the xml2rfc [RFC2629] tools in creating this 3686 document and are very grateful for the existence and quality of these 3687 tools. The editor is also grateful to Elwyn Davies for his help in 3688 correcting the XML source of this document. 3690 11. References 3692 11.1. Normative References 3694 [FE-MODEL] 3695 Yang, L., Halpern, J., Gopal, R., DeKok, A., Haraszti, Z., 3696 and S. Blake, "ForCES Forwarding Element Model", 3697 Feb. 2005. 3699 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3700 Requirement Levels", BCP 14, RFC 2119, March 1997. 3702 [RFC2234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 3703 Specifications: ABNF", RFC 2234, November 1997. 3705 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3706 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 3707 October 1998. 3709 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 3710 of IP Control and Forwarding", RFC 3654, November 2003. 3712 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 3713 "Forwarding and Control Element Separation (ForCES) 3714 Framework", RFC 3746, April 2004. 3716 11.2. Informational References 3718 [2PCREF] Gray, J., "Notes on database operating systems. In 3719 Operating Systems: An Advanced Course. Lecture Notes in 3720 Computer Science, Vol. 60, pp. 394-481, Springer-Verlag", 3721 1978. 3723 [ACID] Haerder, T. and A. Reuter, "Principles of Transaction- 3724 Orientated Database Recovery", 1983. 3726 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 3727 June 1999. 3729 Appendix A. IANA Considerations 3731 Following the policies outlined in "Guidelines for Writing an IANA 3732 Considerations Section in RFCs" (RFC 2434 [RFC2434]), the following 3733 name spaces are defined in ForCES. 3735 o Message Type Name Space Section 7.1.1 3737 o Operation Type Name Space Section 7.1.1.1.6 3739 o Header Flags Section 6.1 3741 o TLV Type Section 7.1.1 3743 o TLV Result Values Section 7.1.1.1.7 3745 o LFB Class ID Section 7.1.1.1.5 3747 o Result: Association Setup Response Section 7.4.2 3749 o Reason: Association Teardown Message Section 7.4.3 3751 A.1. Message Type Name Space 3753 The Message Type is an 8 bit value. The following is the guideline 3754 for defining the Message Type namespace 3756 Message Types 0x00 - 0x0F 3757 Message Types in this range are part of the base ForCES Protocol. 3758 Message Types in this range are allocated through an IETF 3759 consensus action. [RFC2434] 3760 Values assigned by this specification: 3762 0x00 Reserved 3763 0x01 AssociationSetup 3764 0x02 AssociationTeardown 3765 0x03 Config 3766 0x04 Query 3767 0x05 EventNotification 3768 0x06 PacketRedirect 3769 0x07 - 0x0E Reserved 3770 0x0F Hearbeat 3771 0x11 AssociationSetupRepsonse 3772 0x12 Reserved 3773 0x13 ConfigRepsonse 3774 0x14 QueryResponse 3776 Message Types 0x20 - 0x7F 3777 Message Types in this range are Specification Required [RFC2434] 3778 Message Types using this range must be documented in an RFC or 3779 other permanent and readily available reference. 3781 Message Types 0x80 - 0xFF 3782 Message Types in this range are reserved for vendor private 3783 extensions and are the responsibility of individual vendors. IANA 3784 management of this range of the Message Type Name Space is 3785 unnecessary. 3787 A.2. Operation Selection 3789 The Operation Selection (OPERSELECT) name space is 16 bits long. The 3790 following is the guideline for managing the OPERSELECT Name Space. 3792 OPERSELECT Type 0x0000-0x00FF 3793 OPERSELECT Types in this range are allocated through an IETF 3794 consensus process. [RFC2434]. 3795 Values assigned by this specification: 3797 0x0000 Reserved 3798 0x0001 SET 3799 0x0002 SET-PROPERTY 3800 0x0003 SET-RESPONSE 3801 0x0004 SET-PROPERTY-RESPONSE 3802 0x0005 DEL 3803 0x0006 DEL-RESPONSE 3804 0x0007 GET 3805 0x0008 GET-PROPERTY 3806 0x0009 GET-RESPONSE 3807 0x000A GET-PROPERTY-RESPONSE 3808 0x000B REPORT 3809 0x000C COMMIT 3810 0x000D COMMIT-RESPONSE 3812 OPERSELECT Type 0x0100-0x7FFF 3813 OPERSELECT Types using this range must be documented in an RFC or 3814 other permanent and readily available reference. [RFC2434]. 3816 OPERSELECT Type 0x8000-0xFFFF 3817 OPERSELECT Types in this range are reserved for vendor private 3818 extensions and are the responsibility of individual vendors. IANA 3819 management of this range of the OPERSELECT Type Name Space is 3820 unnecessary. 3822 A.3. Header Flags 3824 The Header flag field is 32 bits long. Header flags are part of 3825 the ForCES base protocol. Header flags are allocated through an 3826 IETF consensus action [RFC2434]. 3828 A.4. TLV Type Name Space 3830 The TLV Type name space is 16 bits long. The following is the 3831 guideline for managing the TLV Type Name Space. 3833 TLV Type 0x0000-0x00FF 3834 TLV Types in this range are allocated through an IETF consensus 3835 process. [RFC2434]. 3836 Values assigned by this specification: 3838 0x0000 Reserved 3839 0x0001 REDIRECT-TLV 3840 0x0010 ASResult-TLV 3841 0x0011 ASTreason-TLV 3842 0x1000 LFBselect-TLV 3843 0x0110 PATH-DATA-TLV 3844 0x0111 KEYINFO-TLV 3845 0x0112 FULLDATA-TLV 3846 0x0113 SPARSEDATA-TLV 3847 0x0114 RESULT-TLV 3848 0x0115 METADATA-TLV 3849 0x0116 REDIRECTDATA-TLV 3851 TLV Type 0x0200-0x7FFF 3852 TLV Types using this range must be documented in an RFC or other 3853 permanent and readily available reference [RFC2434]. 3855 TLV Type 0x8000-0xFFFF 3856 TLV Types in this range are reserved for vendor private extensions 3857 and are the responsibility of individual vendors. IANA management 3858 of this range of the TLV Type Name Space is unnecessary. 3860 A.5. Result-TLV Result Values 3862 The RESULT-TLV RTesult Value is an 8 bit value. 3864 0x00 E_SUCCESS 3865 0x01 E_INVALID_HEADER 3866 0x02 E_LENGTH_MISMATCH 3867 0x03 E_VERSION_MISMATCH 3868 0x04 E_INVALID_DESTINATION_PID 3869 0x05 E_LFB_UNKNOWN 3870 0x06 E_LFB_NOT_FOUND 3871 0x07 E_LFB_INSTANCE_ID_NOT_FOUND 3872 0x08 E_INVALID_PATH 3873 0x09 E_ELEMENT_DOES_NOT_EXIST 3874 0x0A E_EXISTS 3875 0x0B E_NOT_FOUND 3876 0x0C E_READ_ONLY 3877 0x0D E_INVALID_ARRAY_CREATION 3878 0x0E E_VALUE_OUT_OF_RANGE 3879 0x0F E_CONTENTS_TOO_LONG 3880 0x10 E_INVALID_PARAMETERS 3881 0x11 E_INVALID_MESSAGE_TYPE 3882 0x12 E_E_INVALID_FLAGS 3883 0x13 E_INVALID_TLV 3884 0x14 E_EVENT_ERROR 3885 0x15 E_NOT_SUPPORTED 3886 0x16 E_MEMORY_ERROR 3887 0x17 E_INTERNAL_ERROR 3888 0x18-0xFE Reserved 3889 0xFF E_UNSPECIFIED_ERROR 3891 All values not assigned in this specification are designated as 3892 Assignment by Expert review. 3894 A.6. Association Setup Response 3896 The Association Setup Response name space is 32 bits long. The 3897 following is the guideline for managing the Association Setup 3898 Response Name Space. 3900 Association Setup Response 0x0000-0x00FF 3901 Association Setup Responses in this range are allocated through an 3902 IETF consensus process [RFC2434]. 3903 Values assigned by this specification: 3905 0x0000 Success 3906 0x0001 FE ID Invalid 3907 0x0002 Permission Denied 3909 Association Setup Response 0x0100-0x0FFF 3910 Association Setup Responses in this range are Specification 3911 Required [RFC2434] Values using this range must be documented in 3912 an RFC or other permanent and readily available reference 3913 [RFC2434]. 3915 Association Setup Response 0x1000-0xFFFFFFFFF 3916 Association Setup Responses in this range are reserved for vendor 3917 private extensions and are the responsibility of individual 3918 vendors. IANA management of this range of the Association Setup 3919 Responses Name Space is unnecessary. 3921 A.7. Association Teardown Message 3923 The Association Teardown Message name space is 32 bits long. The 3924 following is the guideline for managing the Association Teardown 3925 Message Name Space. 3927 Association Teardown Message 0x00000000-0x0000FFFF 3928 Association Teardown Messages in this range are allocated through 3929 an IETF consensus process [RFC2434]. 3930 Values assigned by this specification: 3932 0x00000000 Normal - Teardown by Administrator 3933 0x00000001 Error - loss of heartbeats 3934 0x00000002 Error - loss of bandwidth 3935 0x00000003 Error - Out of Memory 3936 0x00000004 Error - Application Crash 3937 0x000000FF Error - Unspecified 3939 Association Teardown Message 0x00010000-0x7FFFFFFF 3940 Association Teardown Messages in this range are Specification 3941 Required [RFC2434] Association Teardown Messages using this range 3942 must be documented in an RFC or other permanent and readily 3943 available references. [RFC2434]. 3945 Association Teardown Message 0x80000000-0xFFFFFFFFF 3946 Association Teardown Messages in this range are reserved for 3947 vendor private extensions and are the responsibility of individual 3948 vendors. IANA management of this range of the Association 3949 Teardown Message Name Space is unnecessary. 3951 Appendix B. ForCES Protocol LFB schema 3953 The schema described below conforms to the LFB schema described in 3954 ForCES Model draft. [FE-MODEL] 3956 Section 7.2.1 describes the details of the different attributes 3957 defined in this definition. 3959 3964 3965 3966 3967 CEHBPolicyValues 3968 3969 The possible values of CE heartbeat policy 3970 3971 3972 uchar 3973 3974 3975 CEHBPolicy0 3976 3977 The CE heartbeat policy 0 3978 3979 3980 3981 CEHBPolicy1 3982 3983 The CE heartbeat policy 1 3984 3985 3986 3987 3988 3990 3991 FEHBPolicyValues 3992 3993 The possible values of FE heartbeat policy 3994 3995 3996 uchar 3997 3998 3999 FEHBPolicy0 4000 4001 The FE heartbeat policy 0 4002 4003 4004 4005 FEHBPolicy1 4006 4007 The FE heartbeat policy 1 4008 4009 4010 4011 4012 4014 4015 FERestartPolicyValues 4016 4017 The possible values of FE restart policy 4018 4019 4020 uchar 4021 4022 4023 FERestartPolicy0 4024 4025 The FE restart policy 0 4026 4027 4028 4029 4030 4032 4033 CEFailoverPolicyValues 4034 4035 The possible values of CE failover policy 4036 4037 4038 uchar 4039 4040 4041 CEFailoverPolicy0 4042 4043 The CE failover policy 0 4044 4045 4047 4048 CEFailoverPolicy1 4049 4050 The CE failover policy 1 4051 4052 4053 4054 4055 4057 4058 FEHACapab 4059 4060 The supported HA features 4061 4062 4063 uchar 4064 4065 4066 GracefullRestart 4067 4068 The FE supports Graceful Restart 4069 4070 4071 4072 HA 4073 4074 The FE supports HA 4075 4076 4077 4078 4079 4080 4082 4083 4084 FEPO 4085 4086 The FE Protocol Object 4087 4088 1.0 4090 4091 4092 CurrentRunningVersion 4093 Currently running ForCES version 4094 u8 4096 4097 4098 FEID 4099 Unicast FEID 4100 uint32 4101 4102 4103 MulticastFEIDs 4104 4105 the table of all multicast IDs 4106 4107 4108 uint32 4109 4110 4111 4112 CEHBPolicy 4113 4114 The CE Heartbeat Policy 4115 4116 CEHBPolicyValues 4117 4118 4119 CEHDI 4120 4121 The CE Heartbeat Dead Interval in millisecs 4122 4123 uint32 4124 4125 4126 FEHBPolicy 4127 4128 The FE Heartbeat Policy 4129 4130 FEHBPolicyValues 4131 4132 4133 FEHI 4134 4135 The FE Heartbeat Interval in millisecs 4136 4137 uint32 4138 4139 4140 CEID 4141 4142 The Primary CE this FE is associated with 4143 4144 uint32 4145 4146 4147 BackupCEs 4148 4149 The table of all backup CEs other than the primary 4150 4151 4152 uint32 4153 4154 4155 4156 CEFailoverPolicy 4157 4158 The CE Failover Policy 4159 4160 CEFailoverPolicyValues 4161 4163 4164 CEFTI 4165 4166 The CE Failover Timeout Interval in millisecs 4167 4168 uint32 4169 4170 4171 FERestartPolicy 4172 4173 The FE Restart Policy 4174 4175 FERestartPolicyValues 4176 4177 4178 LastCEID 4179 4180 The Primary CE this FE was last associated with 4181 4182 uint32 4183 4184 4186 4187 4188 SupportableVersions 4189 4190 the table of ForCES versions that FE supports 4191 4192 4193 u8 4194 4195 4196 4197 HACapabilities 4198 4199 the table of HA capabilities the FE supports 4200 4201 4202 FEHACapab 4203 4204 4205 4207 4208 4209 PrimaryCEDown 4210 4211 The pimary CE has changed 4212 4213 4214 LastCEID 4215 4216 4217 4218 4219 LastCEID 4220 4221 4222 4223 4225 4226 4227 4229 B.1. Capabilities 4231 Supportable Versions enumerates all ForCES versions that an FE 4232 supports. 4234 FEHACapab enumerates the HA capabilities of the FE. If the FE is not 4235 capable of Graceful restarts or HA, then it will not be able to 4236 participate in HA as described in Section 8.1 4238 B.2. Attributes 4240 All Attributes are explained in Section 7.2.1. 4242 Appendix C. Data Encoding Examples 4244 In this section a few examples of data encoding are discussed. these 4245 example, however, do not show any padding. 4247 ========== 4248 Example 1: 4249 ========== 4251 Structure with three fixed-lengthof, mandatory fields. 4253 struct S { 4254 uint16 a 4255 uint16 b 4256 uint16 c 4257 } 4259 (a) Describing all fields using SPARSEDATA 4261 Path-Data TLV 4262 Path to an instance of S ... 4263 SPARSEDATA TLV 4264 ElementIDof(a), lengthof(a), valueof(a) 4265 ElementIDof(b), lengthof(b), valueof(b) 4266 ElementIDof(c), lengthof(c), valueof(c) 4268 (b) Describing a subset of fields 4270 Path-Data TLV 4271 Path to an instance of S ... 4272 SPARSEDATA TLV 4273 ElementIDof(a), lengthof(a), valueof(a) 4274 ElementIDof(c), lengthof(c), valueof(c) 4276 Note: Even though there are non-optional elements in structure S, 4277 since one can uniquely identify elements, one can selectively send 4278 element of structure S (eg in the case of an update from CE to FE). 4280 (c) Describing all fields using a FULLDATA TLV 4282 Path-Data TLV 4283 Path to an instance of S ... 4284 FULLDATA TLV 4285 valueof(a) 4286 valueof(b) 4287 valueof(c) 4289 ========== 4290 Example 2: 4291 ========== 4293 Structure with three fixed-lengthof fields, one mandatory, two 4294 optional. 4296 struct T { 4297 uint16 a 4298 uint16 b (optional) 4299 uint16 c (optional) 4300 } 4302 This example is identical to Example 1, as illustrated below. 4304 (a) Describing all fields using SPARSEDATA 4306 Path-Data TLV 4307 Path to an instance of S ... 4308 SPARSEDATA TLV 4309 ElementIDof(a), lengthof(a), valueof(a) 4310 ElementIDof(b), lengthof(b), valueof(b) 4311 ElementIDof(c), lengthof(c), valueof(c) 4313 (b) Describing a subset of fields using SPARSEDATA 4315 Path-Data TLV 4316 Path to an instance of S ... 4317 SPARSEDATA TLV 4318 ElementIDof(a), lengthof(a), valueof(a) 4319 ElementIDof(c), lengthof(c), valueof(c) 4321 (c) Describing all fields using a FULLDATA TLV 4323 Path-Data TLV 4324 Path to an instance of S ... 4325 FULLDATA TLV 4326 valueof(a) 4327 valueof(b) 4328 valueof(c) 4330 Note: FULLDATA TLV _cannot_ be used unless all fields are being 4331 described. 4333 ========== 4334 Example 3: 4335 ========== 4336 Structure with a mix of fixed-lengthof and variable-lengthof fields, 4337 some mandatory, some optional. Note in this case, b is variable 4338 sized 4340 struct U { 4341 uint16 a 4342 string b (optional) 4343 uint16 c (optional) 4344 } 4346 (a) Describing all fields using SPARSEDATA 4348 Path to an instance of U ... 4349 SPARSEDATA TLV 4350 ElementIDof(a), lengthof(a), valueof(a) 4351 ElementIDof(b), lengthof(b), valueof(b) 4352 ElementIDof(c), lengthof(c), valueof(c) 4354 (b) Describing a subset of fields using SPARSEDATA 4356 Path to an instance of U ... 4357 SPARSEDATA TLV 4358 ElementIDof(a), lengthof(a), valueof(a) 4359 ElementIDof(c), lengthof(c), valueof(c) 4361 (c) Describing all fields using FULLDATA TLV 4363 Path to an instance of U ... 4364 FULLDATA TLV 4365 valueof(a) 4366 FULLDATA TLV 4367 valueof(b) 4368 valueof(c) 4370 Note: The variable-length field requires the addition of a FULLDATA 4371 TLV within the outer FULLDATA TLV as in the case of element b above. 4373 ========== 4374 Example 4: 4375 ========== 4377 Structure containing an array of another structure type. 4379 struct V { 4380 uint32 x 4381 uint32 y 4382 struct U z[] 4383 } 4385 (a) Encoding using SPARSEDATA, with two instances of z[], also 4386 described with SPARSEDATA, assuming only the 10th and 15th subscript 4387 of z[] are encoded. 4389 path to instance of V ... 4390 SPARSEDATA TLV 4391 ElementIDof(x), lengthof(x), valueof(x) 4392 ElementIDof(y), lengthof(y), valueof(y) 4393 ElementIDof(z), lengthof(all below) 4394 ElementID = 10 (i.e index 10 from z[]), lengthof(all below) 4395 ElementIDof(a), lengthof(a), valueof(a) 4396 ElementIDof(b), lengthof(b), valueof(b) 4397 ElementID = 15 (index 15 from z[]), lengthof(all below) 4398 ElementIDof(a), lengthof(a), valueof(a) 4399 ElementIDof(c), lengthof(c), valueof(c) 4401 Note the holes in the elements of z (10 followed by 15). Also note 4402 the gap in index 15 with only elements a and c appearing but not b. 4404 Appendix D. Use Cases 4406 Assume LFB with following attributes for the following use cases. 4408 foo1, type u32, ID = 1 4410 foo2, type u32, ID = 2 4412 table1: type array, ID = 3 4413 elements are: 4414 t1, type u32, ID = 1 4415 t2, type u32, ID = 2 // index into table 2 4416 KEY: nhkey, ID = 1, V = t2 4418 table2: type array, ID = 4 4419 elements are: 4420 j1, type u32, ID = 1 4421 j2, type u32, ID = 2 4422 KEY: akey, ID = 1, V = { j1,j2 } 4424 table3: type array, ID = 5 4425 elements are: 4426 someid, type u32, ID = 1 4427 name, type string variable sized, ID = 2 4429 table4: type array, ID = 6 4430 elements are: 4431 j1, type u32, ID = 1 4432 j2, type u32, ID = 2 4433 j3, type u32, ID = 3 4434 j4, type u32, ID = 4 4435 KEY: mykey, ID = 1, V = { j1} 4437 table5: type array, ID = 7 4438 elements are: 4439 p1, type u32, ID = 1 4440 p2, type array, ID = 2, array elements of type-X 4442 Type-X: 4443 x1, ID 1, type u32 4444 x2, ID2 , type u32 4445 KEY: tkey, ID = 1, V = { x1} 4447 All examples will use valueof(x) to indicate the value of the 4448 referenced attribute x. In the case where F_SEL** are missing (bits 4449 equal to 00) then the flags will not show any selection. 4451 All the examples only show use of FULLDATA for data encoding; 4452 although SPARSEDATA would make more sense in certain occasions, the 4453 emphasis is on showing the message layout. Refer to Appendix C for 4454 examples that show usage of both FULLDATA and SPARSEDATA. 4456 1. To get foo1 4458 OPER = GET-TLV 4459 Path-data TLV: IDCount = 1, IDs = 1 4460 Result: 4461 OPER = GET-RESPONSE-TLV 4462 Path-data-TLV: 4463 flags=0, IDCount = 1, IDs = 1 4464 FULLDATA-TLV L = 4+4, V = valueof(foo1) 4466 2. To set foo2 to 10 4468 OPER = SET-TLV 4469 Path-data-TLV: 4470 flags = 0, IDCount = 1, IDs = 2 4471 FULLDATA TLV: L = 4+4, V=10 4473 Result: 4474 OPER = SET-RESPONSE-TLV 4475 Path-data-TLV: 4476 flags = 0, IDCount = 1, IDs = 2 4477 RESULT-TLV 4479 3. To dump table2 4481 OPER = GET-TLV 4482 Path-data-TLV: 4483 IDCount = 1, IDs = 4 4484 Result: 4485 OPER = GET-RESPONSE-TLV 4486 Path-data-TLV: 4487 flags = 0, IDCount = 1, IDs = 4 4488 FULLDATA=TLV: L = XXX, V= 4489 a series of: index, valueof(j1), valueof(j2) 4490 representing the entire table 4492 Note: One should be able to take a GET-RESPONSE-TLV and 4493 convert it to a SET-TLV. If the result in the above example 4494 is sent back in a SET-TLV, (instead of a GET-RESPONSE_TLV) 4495 then the entire contents of the table will be replaced at 4496 that point. 4498 4. Multiple operations Example. To create entry 0-5 of table2 4499 (Error conditions are ignored) 4501 OPER = SET-TLV 4502 Path-data-TLV: 4503 flags = 0 , IDCount = 1, IDs=4 4504 PATH-DATA-TLV 4505 flags = 0, IDCount = 1, IDs = 0 4506 FULLDATA-TLV valueof(j1), valueof(j2) of entry 0 4507 PATH-DATA-TLV 4508 flags = 0, IDCount = 1, IDs = 1 4509 FULLDATA-TLV valueof(j1), valueof(j2) of entry 1 4510 PATH-DATA-TLV 4511 flags = 0, IDCount = 1, IDs = 2 4512 FULLDATA-TLV valueof(j1), valueof(j2) of entry 2 4513 PATH-DATA-TLV 4514 flags = 0, IDCount = 1, IDs = 3 4515 FULLDATA-TLV valueof(j1), valueof(j2) of entry 3 4516 PATH-DATA-TLV 4517 flags = 0, IDCount = 1, IDs = 4 4518 FULLDATA-TLV valueof(j1), valueof(j2) of entry 4 4519 PATH-DATA-TLV 4520 flags = 0, IDCount = 1, IDs = 5 4521 FULLDATA-TLV valueof(j1), valueof(j2) of entry 5 4523 Result: 4524 OPER = SET-RESPONSE-TLV 4525 Path-data-TLV: 4526 flags = 0 , IDCount = 1, IDs=4 4527 PATH-DATA-TLV 4528 flags = 0, IDCount = 1, IDs = 0 4529 RESULT-TLV 4530 PATH-DATA-TLV 4531 flags = 0, IDCount = 1, IDs = 1 4532 RESULT-TLV 4533 PATH-DATA-TLV 4534 flags = 0, IDCount = 1, IDs = 2 4535 RESULT-TLV 4536 PATH-DATA-TLV 4537 flags = 0, IDCount = 1, IDs = 3 4538 RESULT-TLV 4539 PATH-DATA-TLV 4540 flags = 0, IDCount = 1, IDs = 4 4541 RESULT-TLV 4542 PATH-DATA-TLV 4543 flags = 0, IDCount = 1, IDs = 5 4544 RESULT-TLV 4546 5. Block operations (with holes) example. Replace entry 0,2 of 4547 table2 4549 OPER = SET-TLV 4550 Path-data TLV: 4551 flags = 0 , IDCount = 1, IDs=4 4552 PATH-DATA-TLV 4553 flags = 0, IDCount = 1, IDs = 0 4554 FULLDATA-TLV containing valueof(j1), valueof(j2) of 0 4555 PATH-DATA-TLV 4556 flags = 0, IDCount = 1, IDs = 2 4557 FULLDATA-TLV containing valueof(j1), valueof(j2) of 2 4559 Result: 4560 OPER = SET-TLV 4561 Path-data TLV: 4562 flags = 0 , IDCount = 1, IDs=4 4563 PATH-DATA-TLV 4564 flags = 0, IDCount = 1, IDs = 0 4565 RESULT-TLV 4566 PATH-DATA-TLV 4567 flags = 0, IDCount = 1, IDs = 2 4568 RESULT-TLV 4570 6. Getting rows example. Get first entry of table2. 4572 OPER = GET-TLV 4573 Path-data TLV: 4574 IDCount = 2, IDs=4.0 4576 Result: 4577 OPER = GET-RESPONSE-TLV 4578 Path-data TLV: 4579 IDCount = 2, IDs=4.0 4580 FULLDATA-TLV containing valueof(j1), valueof(j2) 4582 7. Get entry 0-5 of table2. 4584 OPER = GET-TLV 4585 Path-data-TLV: 4586 flags = 0, IDCount = 1, IDs=4 4587 PATH-DATA-TLV 4588 flags = 0, IDCount = 1, IDs = 0 4589 PATH-DATA-TLV 4590 flags = 0, IDCount = 1, IDs = 1 4591 PATH-DATA-TLV 4592 flags = 0, IDCount = 1, IDs = 2 4593 PATH-DATA-TLV 4594 flags = 0, IDCount = 1, IDs = 3 4595 PATH-DATA-TLV 4596 flags = 0, IDCount = 1, IDs = 4 4597 PATH-DATA-TLV 4598 flags = 0, IDCount = 1, IDs = 5 4600 Result: 4601 OPER = GET-RESPONSE-TLV 4602 Path-data-TLV: 4603 flags = 0, IDCount = 1, IDs=4 4604 PATH-DATA-TLV 4605 flags = 0, IDCount = 1, IDs = 0 4606 FULLDATA-TLV containing valueof(j1), valueof(j2) 4607 PATH-DATA-TLV 4608 flags = 0, IDCount = 1, IDs = 1 4609 FULLDATA-TLV containing valueof(j1), valueof(j2) 4610 PATH-DATA-TLV 4611 flags = 0, IDCount = 1, IDs = 2 4612 FULLDATA-TLV containing valueof(j1), valueof(j2) 4613 PATH-DATA-TLV 4614 flags = 0, IDCount = 1, IDs = 3 4615 FULLDATA-TLV containing valueof(j1), valueof(j2) 4616 PATH-DATA-TLV 4617 flags = 0, IDCount = 1, IDs = 4 4618 FULLDATA-TLV containing valueof(j1), valueof(j2) 4619 PATH-DATA-TLV 4620 flags = 0, IDCount = 1, IDs = 5 4621 FULLDATA-TLV containing valueof(j1), valueof(j2) 4623 8. Create a row in table2, index 5. 4625 OPER = SET-TLV 4626 Path-data-TLV: 4627 flags = 0, IDCount = 2, IDs=4.5 4628 FULLDATA-TLV containing valueof(j1), valueof(j2) 4630 Result: 4631 OPER = SET-RESPONSE-TLV 4632 Path-data TLV: 4633 flags = 0, IDCount = 1, IDs=4.5 4634 RESULT-TLV 4636 9. An example of "create and give me an index" Assuming one asked 4637 for verbose response back in the main message header. 4639 OPER = SET-TLV 4640 Path-data -TLV: 4641 flags = FIND-EMPTY, IDCount = 1, IDs=4 4642 FULLDATA-TLV containing valueof(j1), valueof(j2) 4644 Result 4645 If 7 were the first unused entry in the table: 4646 OPER = SET-RESPONSE 4647 Path-data TLV: 4648 flags = 0, IDCount = 2, IDs=4.7 4649 RESULT-TLV indicating success, and 4650 FULLDATA-TLV containing valueof(j1), valueof(j2) 4652 10. Dump contents of table1. 4654 OPER = GET-TLV 4655 Path-data TLV: 4656 flags = 0, IDCount = 1, IDs=3 4658 Result: 4659 OPER = GET-RESPONSE-TLV 4660 Path-data TLV 4661 flags = 0, IDCount = 1, IDs=3 4662 FULLDATA TLV, Length = XXXX 4663 (depending on size of table1) 4664 index, valueof(t1),valueof(t2) 4665 index, valueof(t1),valueof(t2) 4666 . 4667 . 4668 . 4670 11. Using Keys. Get row entry from table4 where j1=100. Recall, j1 4671 is a defined key for this table and its keyid is 1. 4673 OPER = GET-TLV 4674 Path-data-TLV: 4675 flags = F_SELKEY IDCount = 1, IDs=6 4676 KEYINFO-TLV = KEYID=1, KEY_DATA=100 4678 Result: 4679 If j1=100 was at index 10 4680 OPER = GET-RESPONSE-TLV 4681 Path-data TLV: 4682 flags = 0, IDCount = 1, IDs=6.10 4683 FULLDATA-TLV containing 4684 valueof(j1), valueof(j2),valueof(j3),valueof(j4) 4686 12. Delete row with KEY match (j1=100, j2=200) in table 2. Note 4687 that the j1,j2 pair are a defined key for the table 2. 4689 OPER = DEL-TLV 4690 Path-data TLV: 4691 flags = F_SELKEY IDCount = 1, IDs=4 4692 KEYINFO TLV: {KEYID =1 KEY_DATA=100,200} 4694 Result: 4695 If (j1=100, j2=200) was at entry 15: 4696 OPER = DELETE-RESPONSE-TLV 4697 Path-data TLV: 4698 flags = 0 IDCount = 2, IDs=4.15 4699 RESULT-TLV (with FULLDATA if verbose) 4701 13. Dump contents of table3. It should be noted that this table has 4702 a column with element name that is variable sized. The purpose 4703 of this use case is to show how such an element is to be 4704 encoded. 4706 OPER = GET-TLV 4707 Path-data-TLV: 4708 flags = 0 IDCount = 1, IDs=5 4710 Result: 4711 OPER = GET-RESPONSE-TLV 4712 Path-data TLV: 4713 flags = 0 IDCount = 1, IDs=5 4714 FULLDATA TLV, Length = XXXX 4715 index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), 4716 V = valueof(v) 4717 index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), 4718 V = valueof(v) 4719 index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), 4720 V = valueof(v) 4721 index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), 4722 V = valueof(v) 4723 . 4724 . 4725 . 4727 14. Multiple atomic operations. 4729 Note 1: This emulates adding a new nexthop entry and then 4730 atomically updating the L3 entries pointing to an old NH to 4731 point to a new one. The assumption is both tables are in the 4732 same LFB 4734 Note2: Main header has atomic flag set and the request is for 4735 verbose/full results back; Two operations on the LFB 4736 instance, both are SET operations. 4738 //Operation 1: Add a new entry to table2 index #20. 4739 OPER = SET-TLV 4740 Path-TLV: 4741 flags = 0, IDCount = 2, IDs=4.20 4742 FULLDATA TLV, V= valueof(j1),valueof(j2) 4744 // Operation 2: Update table1 entry which 4745 // was pointing with t2 = 10 to now point to 20 4746 OPER = SET-TLV 4747 Path-data-TLV: 4748 flags = F_SELKEY, IDCount = 1, IDs=3 4749 KEYINFO = KEYID=1 KEY_DATA=10 4750 Path-data-TLV 4751 flags = 0 IDCount = 1, IDs=2 4752 FULLDATA TLV, V= 20 4754 Result: 4755 //first operation, SET 4756 OPER = SET-RESPONSE-TLV 4757 Path-data-TLV 4758 flags = 0 IDCount = 3, IDs=4.20 4759 RESULT-TLV code = success 4760 FULLDATA TLV, V = valueof(j1),valueof(j2) 4761 // second operation SET - assuming entry 16 was updated 4762 OPER = SET-RESPONSE-TLV 4763 Path-data TLV 4764 flags = 0 IDCount = 2, IDs=3.16 4765 Path-Data TLV 4766 flags = 0 IDCount = 1, IDs = 2 4767 SET-RESULT-TLV code = success 4768 FULLDATA TLV, Length = XXXX v=20 4770 15. Selective setting. On table 4 -- for indices 1, 3, 5, 7, and 9. 4771 Replace j1 to 100, j2 to 200, j3 to 300. Leave j4 as is. 4773 PER = SET-TLV 4774 Path-data TLV 4775 flags = 0, IDCount = 1, IDs = 6 4776 Path-data TLV 4777 flags = 0, IDCount = 1, IDs = 1 4778 Path-data TLV 4779 flags = 0, IDCount = 1, IDs = 1 4780 FULLDATA TLV, Length = XXXX, V = {100} 4781 Path-data TLV 4782 flags = 0, IDCount = 1, IDs = 2 4783 FULLDATA TLV, Length = XXXX, V = {200} 4784 Path-data TLV 4785 flags = 0, IDCount = 1, IDs = 3 4786 FULLDATA TLV, Length = XXXX, V = {300} 4787 Path-data TLV 4788 flags = 0, IDCount = 1, IDs = 3 4789 Path-data TLV 4790 flags = 0, IDCount = 1, IDs = 1 4791 FULLDATA TLV, Length = XXXX, V = {100} 4792 Path-data TLV 4793 flags = 0, IDCount = 1, IDs = 2 4794 FULLDATA TLV, Length = XXXX, V = {200} 4795 Path-data TLV 4796 flags = 0, IDCount = 1, IDs = 3 4797 FULLDATA TLV, Length = XXXX, V = {300} 4798 Path-data TLV 4799 flags = 0, IDCount = 1, IDs = 5 4800 Path-data TLV 4801 flags = 0, IDCount = 1, IDs = 1 4802 FULLDATA TLV, Length = XXXX, V = {100} 4803 Path-data TLV 4804 flags = 0, IDCount = 1, IDs = 2 4805 FULLDATA TLV, Length = XXXX, V = {200} 4806 Path-data TLV 4807 flags = 0, IDCount = 1, IDs = 3 4808 FULLDATA TLV, Length = XXXX, V = {300} 4809 Path-data TLV 4810 flags = 0, IDCount = 1, IDs = 7 4811 Path-data TLV 4812 flags = 0, IDCount = 1, IDs = 1 4813 FULLDATA TLV, Length = XXXX, V = {100} 4814 Path-data TLV 4815 flags = 0, IDCount = 1, IDs = 2 4816 FULLDATA TLV, Length = XXXX, V = {200} 4817 Path-data TLV 4818 flags = 0, IDCount = 1, IDs = 3 4819 FULLDATA TLV, Length = XXXX, V = {300} 4820 Path-data TLV 4821 flags = 0, IDCount = 1, IDs = 9 4822 Path-data TLV 4823 flags = 0, IDCount = 1, IDs = 1 4824 FULLDATA TLV, Length = XXXX, V = {100} 4825 Path-data TLV 4826 flags = 0, IDCount = 1, IDs = 2 4827 FULLDATA TLV, Length = XXXX, V = {200} 4828 Path-data TLV 4829 flags = 0, IDCount = 1, IDs = 3 4830 FULLDATA TLV, Length = XXXX, V = {300} 4832 Non-verbose response mode shown: 4834 OPER = SET-RESPONSE-TLV 4835 Path-data TLV 4836 flags = 0, IDCount = 1, IDs = 6 4837 Path-data TLV 4838 flags = 0, IDCount = 1, IDs = 1 4839 Path-data TLV 4840 flags = 0, IDCount = 1, IDs = 1 4841 RESULT-TLV 4842 Path-data TLV 4843 flags = 0, IDCount = 1, IDs = 2 4844 RESULT-TLV 4845 Path-data TLV 4846 flags = 0, IDCount = 1, IDs = 3 4847 RESULT-TLV 4848 Path-data TLV 4849 flags = 0, IDCount = 1, IDs = 3 4850 Path-data TLV 4851 flags = 0, IDCount = 1, IDs = 1 4852 RESULT-TLV 4853 Path-data TLV 4854 flags = 0, IDCount = 1, IDs = 2 4855 RESULT-TLV 4856 Path-data TLV 4857 flags = 0, IDCount = 1, IDs = 3 4858 RESULT-TLV 4859 Path-data TLV 4860 flags = 0, IDCount = 1, IDs = 5 4861 Path-data TLV 4862 flags = 0, IDCount = 1, IDs = 1 4863 RESULT-TLV 4864 Path-data TLV 4865 flags = 0, IDCount = 1, IDs = 2 4866 RESULT-TLV 4867 Path-data TLV 4868 flags = 0, IDCount = 1, IDs = 3 4869 RESULT-TLV 4870 Path-data TLV 4871 flags = 0, IDCount = 1, IDs = 7 4872 Path-data TLV 4873 flags = 0, IDCount = 1, IDs = 1 4874 RESULT-TLV 4875 Path-data TLV 4876 flags = 0, IDCount = 1, IDs = 2 4877 RESULT-TLV 4878 Path-data TLV 4879 flags = 0, IDCount = 1, IDs = 3 4880 RESULT-TLV 4881 Path-data TLV 4882 flags = 0, IDCount = 1, IDs = 9 4883 Path-data TLV 4884 flags = 0, IDCount = 1, IDs = 1 4885 RESULT-TLV 4886 Path-data TLV 4887 flags = 0, IDCount = 1, IDs = 2 4888 RESULT-TLV 4889 Path-data TLV 4890 flags = 0, IDCount = 1, IDs = 3 4891 RESULT-TLV 4893 16. Manipulation of table of table examples. Get x1 from table10 4894 row with index 4, inside table5 entry 10 4896 operation = GET-TLV 4897 Path-data-TLV 4898 flags = 0 IDCount = 5, IDs=7.10.2.4.1 4900 Results: 4901 operation = GET-RESPONSE-TLV 4902 Path-data-TLV 4903 flags = 0 IDCount = 5, IDs=7.10.2.4.1 4904 FULLDATA TLV: L=XXXX, V = valueof(x1) 4906 17. From table5's row 10 table10, get X2s based on on the value of 4907 x1 equaling 10 (recall x1 is KeyID 1) 4909 operation = GET-TLV 4910 Path-data-TLV 4911 flag = F_SELKEY, IDCount=3, IDS = 7.10.2 4912 KEYINFO TLV, KEYID = 1, KEYDATA = 10 4913 Path-data TLV 4914 IDCount = 1, IDS = 2 //select x2 4916 Results: 4917 If x1=10 was at entry 11: 4918 operation = GET-RESPONSE-TLV 4919 Path-data-TLV 4920 flag = 0, IDCount=5, IDS = 7.10.2.11 4921 Path-data TLV 4922 flags = 0 IDCount = 1, IDS = 2 4923 FULLDATA TLV: L=XXXX, V = valueof(x2) 4925 18. Further example of manipulating a table of tables 4927 Consider table 6 which is defined as: 4928 table6: type array, ID = 8 4929 elements are: 4930 p1, type u32, ID = 1 4931 p2, type array, ID = 2, array elements of type type-A 4933 type-A: 4934 a1, type u32, ID 1, 4935 a2, type array ID2 ,array elements of type type-B 4937 type-B: 4938 b1, type u32, ID 1 4939 b2, type u32, ID 2 4941 If for example one wanted to set by replacing: 4942 table6.10.p1 to 111 4943 table6.10.p2.20.a1 to 222 4944 table6.10.p2.20.a2.30.b1 to 333 4946 in one message and one operation. 4948 There are two ways to do this: 4949 a) using nesting 4950 b) using a flat path data 4952 A. Method using nesting 4953 in one message with a single operation 4955 operation = SET-TLV 4956 Path-data-TLV 4957 flags = 0 IDCount = 2, IDs=6.10 4958 Path-data-TLV 4959 flags = 0, IDCount = 1, IDs=1 4960 FULLDATA TLV: L=XXXX, 4961 V = {111} 4962 Path-data-TLV 4963 flags = 0 IDCount = 2, IDs=2.20 4964 Path-data-TLV 4965 flags = 0, IDCount = 1, IDs=1 4966 FULLDATA TLV: L=XXXX, 4967 V = {222} 4968 Path-data TLV : 4969 flags = 0, IDCount = 3, IDs=2.30.1 4970 FULLDATA TLV: L=XXXX, 4971 V = {333} 4972 Result: 4973 operation = SET-RESPONSE-TLV 4974 Path-data-TLV 4975 flags = 0 IDCount = 2, IDs=6.10 4976 Path-data-TLV 4977 flags = 0, IDCount = 1, IDs=1 4978 RESULT-TLV 4979 Path-data-TLV 4980 flags = 0 IDCount = 2, IDs=2.20 4981 Path-data-TLV 4982 flags = 0, IDCount = 1, IDs=1 4983 RESULT-TLV 4984 Path-data TLV : 4985 flags = 0, IDCount = 3, IDs=2.30.1 4986 RESULT-TLV 4988 B. Method using a flat path data in 4989 one message with a single operation 4991 operation = SET-TLV 4992 Path-data TLV : 4993 flags = 0, IDCount = 3, IDs=6.10.1 4994 FULLDATA TLV: L=XXXX, 4995 V = {111} 4996 Path-data TLV : 4997 flags = 0, IDCount = 5, IDs=6.10.1.20.1 4998 FULLDATA TLV: L=XXXX, 4999 V = {222} 5000 Path-data TLV : 5001 flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1 5002 FULLDATA TLV: L=XXXX, 5003 V = {333} 5004 Result: 5005 operation = SET-TLV 5006 Path-data TLV : 5007 flags = 0, IDCount = 3, IDs=6.10.1 5008 RESULT-TLV 5009 Path-data TLV : 5010 flags = 0, IDCount = 5, IDs=6.10.1.20.1 5011 RESULT-TLV 5012 Path-data TLV : 5013 flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1 5014 RESULT-TLV 5016 19. Get a whole LFB (all its attributes, etc.). 5018 For example: at startup a CE might well want the entire FE 5019 OBJECT LFB. So, in a request targeted at class 1, instance 5020 1, one might find: 5022 operation = GET-TLV 5023 Path-data-TLV 5024 flags = 0 IDCount = 0 5026 result: 5027 operation = GET-RESPONSE-TLV 5028 Path-data-TLV 5029 flags = 0 IDCount = 0 5030 FULLDATA encoding of the FE Object LFB 5032 Authors' Addresses 5034 Ligang Dong 5035 Zhejiang Gongshang University 5036 149 Jiaogong Road 5037 Hangzhou 310035 5038 P.R.China 5040 Phone: +86-571-88071024 5041 Email: donglg@mail.zjgsu.edu.cn 5043 Avri Doria 5044 ETRI 5045 Lulea University of Technology 5046 Lulea 5047 Sweden 5049 Phone: +46 73 277 1788 5050 Email: avri@ltu.se 5052 Ram Gopal 5053 Nokia 5054 5, Wayside Road 5055 Burlington, MA 310035 5056 USA 5058 Phone: +1-781-993-3685 5059 Email: ram.gopal@nokia.com 5061 Robert Haas 5062 IBM 5063 Saumerstrasse 4 5064 8803 Ruschlikon 5065 Switzerland 5067 Phone: 5068 Email: rha@zurich.ibm.com 5069 Jamal Hadi Salim 5070 Znyx 5071 Ottawa, Ontario 5072 Canada 5074 Phone: 5075 Email: hadi@znyx.com 5077 Hormuzd M Khosravi 5078 Intel 5079 2111 NE 25th Avenue 5080 Hillsboro, OR 97124 5081 USA 5083 Phone: +1 503 264 0334 5084 Email: hormuzd.m.khosravi@intel.com 5086 Weiming Wang 5087 Zhejiang Gongshang University 5088 149 Jiaogong Road 5089 Hangzhou 310035 5090 P.R.China 5092 Phone: +86-571-88057712 5093 Email: wmwang@mail.zjgsu.edu.cn 5095 Full Copyright Statement 5097 Copyright (C) The IETF Trust (2007). 5099 This document is subject to the rights, licenses and restrictions 5100 contained in BCP 78, and except as set forth therein, the authors 5101 retain all their rights. 5103 This document and the information contained herein are provided on an 5104 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 5105 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 5106 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 5107 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 5108 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 5109 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 5111 Intellectual Property 5113 The IETF takes no position regarding the validity or scope of any 5114 Intellectual Property Rights or other rights that might be claimed to 5115 pertain to the implementation or use of the technology described in 5116 this document or the extent to which any license under such rights 5117 might or might not be available; nor does it represent that it has 5118 made any independent effort to identify any such rights. Information 5119 on the procedures with respect to rights in RFC documents can be 5120 found in BCP 78 and BCP 79. 5122 Copies of IPR disclosures made to the IETF Secretariat and any 5123 assurances of licenses to be made available, or the result of an 5124 attempt made to obtain a general license or permission for the use of 5125 such proprietary rights by implementers or users of this 5126 specification can be obtained from the IETF on-line IPR repository at 5127 http://www.ietf.org/ipr. 5129 The IETF invites any interested party to bring to its attention any 5130 copyrights, patents or patent applications, or other proprietary 5131 rights that may cover technology that may be required to implement 5132 this standard. Please address the information to the IETF at 5133 ietf-ipr@ietf.org. 5135 Acknowledgment 5137 Funding for the RFC Editor function is provided by the IETF 5138 Administrative Support Activity (IASA).