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