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