idnits 2.17.1 draft-ietf-forces-protocol-11.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 5141. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 5152. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 5159. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 5165. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 'NoACK' (0b00) - to indicate that the message receiver MUST not send any response message back to this message sender. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 8, 2007) is 6137 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 1810, but not defined == Missing Reference: 'SELECTOR' is mentioned on line 1811, but not defined -- Possible downref: Non-RFC (?) normative reference: ref. 'FE-MODEL' ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 2 errors (**), 0 flaws (~~), 6 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Doria (Ed.) 3 Internet-Draft Lulea University of Technology 4 Intended status: Standards Track R. Haas (Ed.) 5 Expires: January 9, 2008 IBM 6 J. Hadi Salim (Ed.) 7 Znyx 8 H. Khosravi (Ed.) 9 Intel 10 W. M. Wang (Ed.) 11 Zhejiang Gongshang University 13 July 8, 2007 15 ForCES Protocol Specification 16 draft-ietf-forces-protocol-11.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 January 9, 2008. 43 Copyright Notice 45 Copyright (C) The IETF Trust (2007). 47 Abstract 49 This document specifies the Forwarding and Control Element Separation 50 (ForCES) protocol. ForCES protocol is used for communications 51 between Control Elements(CEs) and Forwarding Elements (FEs) in a 52 ForCES Network Element (ForCES NE). This specification is intended 53 to meet the ForCES protocol requirements defined in RFC3654. Besides 54 the ForCES protocol messages, the specification also defines the 55 framework, the mechanisms, and the Transport Mapping Layer (TML) 56 requirements for ForCES protocol. 58 Authors 60 The participants in the ForCES Protocol Team, primary co-authors and 61 co-editors, of this protocol specification, are: 63 Ligang Dong (Zhejiang Gongshang University), Avri Doria (Lulea 64 University of Technology), Ram Gopal (Nokia), Robert Haas (IBM), 65 Jamal Hadi Salim (Znyx), Hormuzd M Khosravi (Intel), and Weiming Wang 66 (Zhejiang Gongshang University). 68 Table of Contents 70 1. Terminology and Conventions . . . . . . . . . . . . . . . . . 6 71 1.1. Other Notation . . . . . . . . . . . . . . . . . . . . . 6 72 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 7 73 3. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 9 74 4. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 12 75 4.1. Protocol Framework . . . . . . . . . . . . . . . . . . . 12 76 4.1.1. The PL . . . . . . . . . . . . . . . . . . . . . . . 14 77 4.1.2. The TML . . . . . . . . . . . . . . . . . . . . . . . 15 78 4.1.3. The FEM/CEM Interface . . . . . . . . . . . . . . . . 15 79 4.2. ForCES Protocol Phases . . . . . . . . . . . . . . . . . 16 80 4.2.1. Pre-association . . . . . . . . . . . . . . . . . . . 17 81 4.2.2. Post-association . . . . . . . . . . . . . . . . . . 18 82 4.3. Protocol Mechanisms . . . . . . . . . . . . . . . . . . . 20 83 4.3.1. Transactions, Atomicity, Execution and Responses . . 20 84 4.3.2. Scalability . . . . . . . . . . . . . . . . . . . . . 26 85 4.3.3. Heartbeat Mechanism . . . . . . . . . . . . . . . . . 27 86 4.3.4. FE Object and FE Protocol LFBs . . . . . . . . . . . 27 87 4.4. Protocol Scenarios . . . . . . . . . . . . . . . . . . . 28 88 4.4.1. Association Setup State . . . . . . . . . . . . . . . 28 89 4.4.2. Association Established state or Steady State . . . . 29 90 5. TML Requirements . . . . . . . . . . . . . . . . . . . . . . 32 91 5.1. TML Parameterization . . . . . . . . . . . . . . . . . . 33 92 6. Message Encapsulation . . . . . . . . . . . . . . . . . . . . 34 93 6.1. Common Header . . . . . . . . . . . . . . . . . . . . . . 34 94 6.2. Type Length Value (TLV) Structuring . . . . . . . . . . . 39 95 6.2.1. Nested TLVs . . . . . . . . . . . . . . . . . . . . . 40 96 6.2.2. Scope of the T in TLV . . . . . . . . . . . . . . . . 40 97 6.3. ILV . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 98 6.4. Important Protocol encapsulations . . . . . . . . . . . . 41 99 6.4.1. Paths . . . . . . . . . . . . . . . . . . . . . . . . 41 100 6.4.2. Keys . . . . . . . . . . . . . . . . . . . . . . . . 42 101 6.4.3. DATA TLVs . . . . . . . . . . . . . . . . . . . . . . 42 102 6.4.4. Addressing LFB entities . . . . . . . . . . . . . . . 42 103 7. Protocol Construction . . . . . . . . . . . . . . . . . . . . 44 104 7.1. Discussion on encoding . . . . . . . . . . . . . . . . . 48 105 7.1.1. Data Packing Rules . . . . . . . . . . . . . . . . . 48 106 7.1.2. Path Flags . . . . . . . . . . . . . . . . . . . . . 48 107 7.1.3. Relation of operational flags with global message 108 flags . . . . . . . . . . . . . . . . . . . . . . . . 49 109 7.1.4. Content Path Selection . . . . . . . . . . . . . . . 49 110 7.1.5. LFBselect-TLV . . . . . . . . . . . . . . . . . . . . 49 111 7.1.6. OPER-TLV . . . . . . . . . . . . . . . . . . . . . . 50 112 7.1.7. Result TLV . . . . . . . . . . . . . . . . . . . . . 52 113 7.1.8. DATA TLV . . . . . . . . . . . . . . . . . . . . . . 55 114 7.1.9. SET and GET Relationship . . . . . . . . . . . . . . 56 115 7.2. Protocol Encoding Visualization . . . . . . . . . . . . . 57 116 7.3. Core ForCES LFBs . . . . . . . . . . . . . . . . . . . . 60 117 7.3.1. FE Protocol LFB . . . . . . . . . . . . . . . . . . . 61 118 7.3.2. FE Object LFB . . . . . . . . . . . . . . . . . . . . 64 119 7.4. Semantics of Message Direction . . . . . . . . . . . . . 64 120 7.5. Association Messages . . . . . . . . . . . . . . . . . . 65 121 7.5.1. Association Setup Message . . . . . . . . . . . . . . 65 122 7.5.2. Association Setup Response Message . . . . . . . . . 67 123 7.5.3. Association Teardown Message . . . . . . . . . . . . 68 124 7.6. Configuration Messages . . . . . . . . . . . . . . . . . 70 125 7.6.1. Config Message . . . . . . . . . . . . . . . . . . . 70 126 7.6.2. Config Response Message . . . . . . . . . . . . . . . 72 127 7.7. Query Messages . . . . . . . . . . . . . . . . . . . . . 74 128 7.7.1. Query Message . . . . . . . . . . . . . . . . . . . . 74 129 7.7.2. Query Response Message . . . . . . . . . . . . . . . 76 130 7.8. Event Notification Message . . . . . . . . . . . . . . . 78 131 7.9. Packet Redirect Message . . . . . . . . . . . . . . . . . 80 132 7.10. Heartbeat Message . . . . . . . . . . . . . . . . . . . . 82 133 8. High Availability Support . . . . . . . . . . . . . . . . . . 84 134 8.1. Relation with the FE Protocol . . . . . . . . . . . . . . 84 135 8.2. Responsibilities for HA . . . . . . . . . . . . . . . . . 87 136 9. Security Considerations . . . . . . . . . . . . . . . . . . . 89 137 9.1. No Security . . . . . . . . . . . . . . . . . . . . . . . 89 138 9.1.1. Endpoint Authentication . . . . . . . . . . . . . . . 89 139 9.1.2. Message authentication . . . . . . . . . . . . . . . 90 140 9.2. ForCES PL and TML security service . . . . . . . . . . . 90 141 9.2.1. Endpoint authentication service . . . . . . . . . . . 90 142 9.2.2. Message authentication service . . . . . . . . . . . 90 143 9.2.3. Confidentiality service . . . . . . . . . . . . . . . 90 144 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 91 145 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 92 146 11.1. Normative References . . . . . . . . . . . . . . . . . . 92 147 11.2. Informational References . . . . . . . . . . . . . . . . 92 148 Appendix A. IANA Considerations . . . . . . . . . . . . . . . . 93 149 A.1. Message Type Name Space . . . . . . . . . . . . . . . . . 93 150 A.2. Operation Selection . . . . . . . . . . . . . . . . . . . 94 151 A.3. Header Flags . . . . . . . . . . . . . . . . . . . . . . 95 152 A.4. TLV Type Name Space . . . . . . . . . . . . . . . . . . . 95 153 A.5. Result-TLV Result Values . . . . . . . . . . . . . . . . 95 154 A.6. Association Setup Response . . . . . . . . . . . . . . . 96 155 A.7. Association Teardown Message . . . . . . . . . . . . . . 97 156 Appendix B. ForCES Protocol LFB schema . . . . . . . . . . . . . 98 157 B.1. Capabilities . . . . . . . . . . . . . . . . . . . . . . 103 158 B.2. Attributes . . . . . . . . . . . . . . . . . . . . . . . 104 159 Appendix C. Data Encoding Examples . . . . . . . . . . . . . . . 105 160 Appendix D. Use Cases . . . . . . . . . . . . . . . . . . . . . 109 161 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 124 162 Intellectual Property and Copyright Statements . . . . . . . . . 126 164 1. Terminology and Conventions 166 The key words MUST, MUST NOT, REQUIRED, SHOULD, SHOULD NOT, 167 RECOMMENDED, MAY, and OPTIONAL in this document are to be interpreted 168 as described in BCP 14, RFC2119 [RFC2119]. 170 1.1. Other Notation 172 In table Table 1 and table Table 2 the following notation is used to 173 indicate multiplicity: 175 (value)+ .... means "1 or more instance of value" 177 (value)* .... means "0 or more instance of value" 179 2. Introduction 181 Forwarding and Control Element Separation (ForCES) defines an 182 architectural framework and associated protocols to standardize 183 information exchange between the control plane and the forwarding 184 plane in a ForCES Network Element (ForCES NE). RFC 3654 has defined 185 the ForCES requirements, and RFC 3746 has defined the ForCES 186 framework. While there may be multiple protocols used within the 187 overall ForCES architecture, the term "ForCES protocol" and 188 "protocol" as used in this document refers to the protocol used to 189 standardize the information exchange between Control Elements (CEs) 190 and Forwarding Elements (FEs) only. 192 The ForCES FE model [FE-MODEL] presents a formal way to define FE 193 Logical Function Blocks (LFBs) using XML. LFB configuration 194 attributes, capabilities, and associated events are defined when the 195 LFB is formally created. The LFBs within the FE are accordingly 196 controlled in a standardized way by the ForCES protocol. 198 This document defines the ForCES protocol specifications. The ForCES 199 protocol works in a master-slave mode in which FEs are slaves and CEs 200 are masters. The protocol includes commands for transport of Logical 201 Function Block(LFB) configuration information, association setup, 202 status, and event notifications, etc. 204 This specification does not define a transport mechanism for protocol 205 messages. A discussion of service primitives that must be provided 206 by the underlying transport interface will be discussed in a future 207 document. 209 Section 3 provides a glossary of terminology used in the 210 specification. 212 Section 4 provides an overview of the protocol, including a 213 discussion on the protocol framework, descriptions of the Protocol 214 Layer (PL) and a Transport Mapping Layer (TML), as well as of the 215 ForCES protocol mechanisms. Section 4.4 describes several Protocol 216 scenarios and includes message exchange descriptions. 218 While this document does not define the TML, Section 5 details the 219 services that a TML must provide (TML requirements). 221 The ForCES protocol defines a common header for all protocol 222 messages. The header is defined in Section 6.1, while the protocol 223 messages are defined in Section 7. 225 Section 8 describes the protocol support for high availability 226 mechanisms including redundancy and fail over. 228 Section 9 defines the security mechanisms provided by the PL and TML. 230 3. Definitions 232 This document follows the terminology defined by the ForCES 233 Requirements in [RFC3654] and by the ForCES framework in [RFC3746]. 234 The definitions below are repeated below for clarity. 236 Addressable Entity (AE) - A physical device that is directly 237 addressable given some interconnect technology. For example, on IP 238 networks, it is a device which can be reached using an IP address; 239 and on a switch fabric, it is a device which can be reached using a 240 switch fabric port number. 242 Control Element (CE) - A logical entity that implements the ForCES 243 protocol and uses it to instruct one or more FEs on how to process 244 packets. CEs handle functionality such as the execution of control 245 and signaling protocols. 247 CE Manager (CEM) - A logical entity responsible for generic CE 248 management tasks. It is particularly used during the pre-association 249 phase to determine with which FE(s) a CE should communicate. This 250 process is called FE discovery and may involve the CE manager 251 learning the capabilities of available FEs. 253 Datapath - A conceptual path taken by packets within the forwarding 254 plane inside an FE. 256 Forwarding Element (FE) - A logical entity that implements the ForCES 257 protocol. FEs use the underlying hardware to provide per-packet 258 processing and handling as directed/controlled by one or more CEs via 259 the ForCES protocol. 261 FE Model - A model that describes the logical processing functions of 262 an FE. The FE model is defined using Logical Function Blocks (LFBs). 264 FE Manager (FEM) - A logical entity responsible for generic FE 265 management tasks. It is used during pre-association phase to 266 determine with which CE(s) an FE should communicate. This process is 267 called CE discovery and may involve the FE manager learning the 268 capabilities of available CEs. An FE manager may use anything from a 269 static configuration to a pre-association phase protocol (see below) 270 to determine which CE(s) to use. Being a logical entity, an FE 271 manager might be physically combined with any of the other logical 272 entities such as FEs. 274 ForCES Network Element (NE) - An entity composed of one or more CEs 275 and one or more FEs. To entities outside an NE, the NE represents a 276 single point of management. Similarly, an NE usually hides its 277 internal organization from external entities. 279 High Touch Capability - This term will be used to apply to the 280 capabilities found in some forwarders to take action on the contents 281 or headers of a packet based on content other than what is found in 282 the IP header. Examples of these capabilities include NAT-PT, 283 firewall, and L7 content recognition. 285 Inter-FE Topology - See FE Topology. 287 Intra-FE Topology - See LFB Topology. 289 LFB (Logical Function Block) - The basic building block that is 290 operated on by the ForCES protocol. The LFB is a well defined, 291 logically separable functional block that resides in an FE and is 292 controlled by the CE via ForCES protocol. The LFB may reside at the 293 FE's datapath and process packets or may be purely an FE control or 294 configuration entity that is operated on by the CE. Note that the 295 LFB is a functionally accurate abstraction of the FE's processing 296 capabilities, but not a hardware-accurate representation of the FE 297 implementation. 299 FE Topology - A representation of how the multiple FEs within a 300 single NE are interconnected. Sometimes this is called inter-FE 301 topology, to be distinguished from intra-FE topology (i.e., LFB 302 topology). 304 LFB Class and LFB Instance - LFBs are categorized by LFB Classes. An 305 LFB Instance represents an LFB Class (or Type) existence. There may 306 be multiple instances of the same LFB Class (or Type) in an FE. An 307 LFB Class is represented by an LFB Class ID, and an LFB Instance is 308 represented by an LFB Instance ID. As a result, an LFB Class ID 309 associated with an LFB Instance ID uniquely specifies an LFB 310 existence. 312 LFB Metadata - Metadata is used to communicate per-packet state from 313 one LFB to another, but is not sent across the network. The FE model 314 defines how such metadata is identified, produced and consumed by the 315 LFBs. It defines the functionality but not how metadata is encoded 316 within an implementation. 318 LFB Attribute - Operational parameters of the LFBs that must be 319 visible to the CEs are conceptualized in the FE model as the LFB 320 attributes. The LFB attributes include, for example, flags, single 321 parameter arguments, complex arguments, and tables that the CE can 322 read and/or write via the ForCES protocol (see below). 324 LFB Topology - Representation of how the LFB instances are logically 325 interconnected and placed along the datapath within one FE. 326 Sometimes it is also called intra-FE topology, to be distinguished 327 from inter-FE topology. 329 Pre-association Phase - The period of time during which an FE Manager 330 and a CE Manager are determining which FE(s) and CE(s) should be part 331 of the same network element. 333 Post-association Phase - The period of time during which an FE knows 334 which CE is to control it and vice versa. This includes the time 335 during which the CE and FE are establishing communication with one 336 another. 338 ForCES Protocol - While there may be multiple protocols used within 339 the overall ForCES architecture, the term "ForCES protocol" and 340 "protocol" refer to the Fp reference point in the ForCES Framework in 341 [RFC3746]. This protocol does not apply to CE-to-CE communication, 342 FE-to-FE communication, or to communication between FE and CE 343 managers. Basically, the ForCES protocol works in a master-slave 344 mode in which FEs are slaves and CEs are masters. This document 345 defines the specifications for this ForCES protocol. 347 ForCES Protocol Layer (ForCES PL) - A layer in ForCES protocol 348 architecture that defines the ForCES protocol messages, the protocol 349 state transfer scheme, as well as the ForCES protocol architecture 350 itself (including requirements of ForCES TML as shown below). 351 Specifications of ForCES PL are defined by this document. 353 ForCES Protocol Transport Mapping Layer (ForCES TML) - A layer in 354 ForCES protocol architecture that uses the capabilities of existing 355 transport protocols to specifically address protocol message 356 transportation issues, such as how the protocol messages are mapped 357 to different transport media (like TCP, IP, ATM, Ethernet, etc), and 358 how to achieve and implement reliability, multicast, ordering, etc. 359 The ForCES TML specifications are detailed in separate ForCES 360 documents, one for each TML. 362 4. Overview 364 The reader is referred to the Framework document [RFC3746], and in 365 particular sections 3 and 4, for an architectural overview and an 366 explanation of how the ForCES protocol fits in. There may be some 367 content overlap between the framework document and this section in 368 order to provide clarity. This document is authoritative on the 369 protocol whereas [RFC3746] is authoritative on the architecture. 371 4.1. Protocol Framework 373 Figure 1 below is reproduced from the Framework document for clarity. 374 It shows a NE with two CEs and two FEs. 376 --------------------------------------- 377 | ForCES Network Element | 378 -------------- Fc | -------------- -------------- | 379 | CE Manager |---------+-| CE 1 |------| CE 2 | | 380 -------------- | | | Fr | | | 381 | | -------------- -------------- | 382 | Fl | | | Fp / | 383 | | Fp| |----------| / | 384 | | | |/ | 385 | | | | | 386 | | | Fp /|----| | 387 | | | /--------/ | | 388 -------------- Ff | -------------- -------------- | 389 | FE Manager |---------+-| FE 1 | Fi | FE 2 | | 390 -------------- | | |------| | | 391 | -------------- -------------- | 392 | | | | | | | | | | 393 ----+--+--+--+----------+--+--+--+----- 394 | | | | | | | | 395 | | | | | | | | 396 Fi/f Fi/f 398 Fp: CE-FE interface 399 Fi: FE-FE interface 400 Fr: CE-CE interface 401 Fc: Interface between the CE Manager and a CE 402 Ff: Interface between the FE Manager and an FE 403 Fl: Interface between the CE Manager and the FE Manager 404 Fi/f: FE external interface 406 Figure 1: ForCES Architectural Diagram 408 The ForCES protocol domain is found in the Fp Reference Point. The 409 Protocol Element configuration reference points, Fc and Ff also play 410 a role in the booting up of the ForCES Protocol. The protocol 411 element configuration (indicated by reference points Fc, Ff, and Fl 412 in [RFC3746] ) is out of scope of the ForCES protocol but is touched 413 on in this document in discussion of FEM and CEM since it is an 414 integral part of the protocol pre-association phase. 416 Figure 2 below shows further breakdown of the Fp interface by example 417 of an MPLS QoS enabled Network Element. 419 ------------------------------------------------- 420 | | | | | | | 421 |OSPF |RIP |BGP |RSVP |LDP |. . . | 422 | | | | | | | 423 ------------------------------------------------- CE 424 | ForCES Interface | 425 ------------------------------------------------- 426 ^ ^ 427 | | 428 ForCES | |data 429 control | |packets 430 messages| |(e.g., routing packets) 431 | | 432 v v 433 ------------------------------------------------- 434 | ForCES Interface | 435 ------------------------------------------------- FE 436 | | | | | | | 437 |LPM Fwd|Meter |Shaper |MPLS |Classi-|. . . | 438 | | | | |fier | | 439 ------------------------------------------------- 441 Figure 2: Examples of CE and FE functions 443 The ForCES Interface shown in Figure 2 constitutes two pieces: the PL 444 and the TML. 446 This is depicted in Figure 3 below. 448 +------------------------------------------------ 449 | CE PL | 450 +------------------------------------------------ 451 | CE TML | 452 +------------------------------------------------ 453 ^ 454 | 455 ForCES | (i.e ForCES data + control 456 PL | packets ) 457 messages | 458 over | 459 specific | 460 TML | 461 encaps | 462 and | 463 transport | 464 | 465 v 466 +------------------------------------------------ 467 | FE TML | 468 +------------------------------------------------ 469 | FE PL | 470 +------------------------------------------------ 472 Figure 3: ForCES Interface 474 The PL is in fact the ForCES protocol. Its semantics and message 475 layout are defined in this document. The TML Layer is necessary to 476 connect two ForCES PLs as shown in Figure 3 above. The TML is out of 477 scope for this document but is within scope of ForCES. This document 478 defines requirements the PL needs the TML to meet. 480 Both the PL and the TML are standardized by the IETF. While only one 481 PL is defined, different TMLs are expected to be standardized. To 482 interoperate the TML at the CE and FE are expected to conform to the 483 same definition. 485 On transmit, the PL delivers its messages to the TML. The local TML 486 delivers the message to the destination TML. On receive, the TML 487 delivers the message to its destination PL. 489 4.1.1. The PL 491 The PL is common to all implementations of ForCES and is standardized 492 by the IETF as defined in this document. The PL is responsible for 493 associating an FE or CE to an NE. It is also responsible for tearing 494 down such associations. An FE uses the PL to transmit various 495 subscribed-to events to the CE PL as well as to respond to various 496 status requests issued from the CE PL. The CE configures both the FE 497 and associated LFBs' operational parameters using the PL. In 498 addition the CE may send various requests to the FE to activate or 499 deactivate it, reconfigure its HA parameterization, subscribe to 500 specific events etc. More details can be found in Section 7. 502 4.1.2. The TML 504 The TML transports the PL messages. The TML is where the issues of 505 how to achieve transport level reliability, congestion control, 506 multicast, ordering, etc. are handled. It is expected that more than 507 one TML will be standardized. The various possible TMLs could vary 508 their implementations based on the capabilities of underlying media 509 and transport. However, since each TML is standardized, 510 interoperability is guaranteed as long as both endpoints support the 511 same TML. All ForCES Protocol Layer implementations MUST be portable 512 across all TMLs, because all TMLs MUST have the top edge semantics 513 defined in this document. 515 4.1.3. The FEM/CEM Interface 517 The FEM and CEM components, although valuable in the setup and 518 configurations of both the PL and TML, are out of scope of the ForCES 519 protocol. The best way to think of them is as configurations/ 520 parameterizations for the PL and TML before they become active (or 521 even at runtime based on implementation). In the simplest case, the 522 FE or CE reads a static configuration file. RFC 3746 has a more 523 detailed description on how the FEM and CEM could be used. The pre- 524 association phase, where the CEM and FEM can be used, are described 525 briefly in Section 4.2.1. 527 An example of typical things the FEM/CEM could configure would be TML 528 specific parameterizations such as: 530 a. How the TML connection should happen (for example what IP 531 addresses to use, transport modes etc); 533 b. The ID for the FE or CE (which would also be issued during the 534 pre-association phase). 536 c. Security parameterization such as keys etc. 538 d. Connection association parameters 540 Example of connection association parameters this might be: 542 o simple parameters: send up to 3 association messages every 1 543 second 545 o complex parameters: send up to 4 association messages with 546 increasing exponential timeout 548 4.2. ForCES Protocol Phases 550 ForCES, in relation to NEs, involves two phases: the Pre-Association 551 phase, where configuration/initialization/bootup of the TML and PL 552 layer happens, and the association phase where the ForCES protocol 553 operates to manipulate the parameters of the FEs. 555 FE associated CE configures transition to UP 556 +---->--->---+ +--->---->---->---->------->----+ 557 | | | Y 558 ^ Y | | 559 | | | Y 560 +---+-------+ +------+--+ +--------+ 561 |FE Pre- | | FE | | FE | 562 |Association| | DOWN | CE configures DOWN | UP | 563 |Phase | | State +<------<-----<------<-- + State | 564 | | | | | | 565 +-----------+ +---------+ +--------+ 566 ^ Y 567 | | 568 +-<---<------<-----<------<----<---------<------+ 569 FE loses association 571 Figure 4: The FE State Machine 573 In the mandated case, once associated, the FE can only be in one of 574 two states, as indicated above. When the FE is in the DOWN state, it 575 is not forwarding packets. When the FE is in the UP state it may be 576 forwarding packets, depending on the configuration of its specific 577 LFBs. The FE MAY also be in other states when it is capable of 578 graceful restart and high availability. The extra transitions are 579 explained in Section 8 and not discussed here so as to allow us to 580 explain the basics with more clarity. 582 The CE configures FE state transitions by means of the FE Object LFB, 583 which is defined in [FE-MODEL] and also explained in Section 7.3.2. 584 In the FE Object LFB, FE state is defined as an attribute of the LFB, 585 and CE configuration of the FE state equals CE configuration of this 586 attribute. Note that even in the FE DOWN state, the FE is 587 associated. 589 The FE stays in the DOWN state until it is explicitly configured by 590 the CE to transition to the UP state via an FE Object admin action. 591 This must be done before configuring any other LFBs that affect 592 packet forwarding. The typical setup will bring up the FE to the UP 593 state on association. 595 The FE transitions from the UP state to the DOWN state when it 596 receives an FEObject Admin Down action. when it loses its association 597 with the CE it may go into the pre-association phase depending on the 598 programmed policy. For the FE to properly complete the transition to 599 the DOWN state, it MUST stop Packet forwarding and this may impact 600 multiple LFBS. How this is achieved is outside the scope of this 601 specification. 603 4.2.1. Pre-association 605 The ForCES interface is configured during the pre-association phase. 606 In a simple setup, the configuration is static and is read from a 607 saved configuration file. All the parameters for the association 608 phase are well known after the pre-association phase is complete. A 609 protocol such as DHCP may be used to retrieve the configuration 610 parameters instead of reading them from a static configuration file. 611 Note, this will still be considered static pre-association. Dynamic 612 configuration may also happen using the Fc, Ff and Fl reference 613 points (refer to [RFC3746]). Vendors may use their own proprietary 614 service discovery protocol to pass the parameters. Essentially, only 615 guidelines are provided here and the details are left to the 616 implementation. 618 The following are scenarios reproduced from the Framework Document to 619 show a pre-association example. 621 <----Ff ref pt---> <--Fc ref pt-------> 622 FE Manager FE CE Manager CE 623 | | | | 624 | | | | 625 (security exchange) (security exchange) 626 1|<------------>| authentication 1|<----------->|authentication 627 | | | | 628 (FE ID, attributes) (CE ID, attributes) 629 2|<-------------| request 2|<------------|request 630 | | | | 631 3|------------->| response 3|------------>|response 632 (corresponding CE ID) (corresponding FE ID) 633 | | | | 634 | | | | 636 Figure 5: Examples of a message exchange over the Ff and Fc reference 637 points 639 <-----------Fl ref pt--------------> | 641 FE Manager FE CE Manager CE 642 | | | | 643 | | | | 644 (security exchange) | | 645 1|<------------------------------>| | 646 | | | | 647 (a list of CEs and their attributes) | 648 2|<-------------------------------| | 649 | | | | 650 (a list of FEs and their attributes) | 651 3|------------------------------->| | 652 | | | | 653 | | | | 655 Figure 6: An example of a message exchange over the Fl reference 656 point 658 Before the transition to the association phase, the FEM will have 659 established contact with a CEM component. Initialization of the 660 ForCES interface will have completed, and authentication as well as 661 capability discovery may be complete. Both the FE and CE would have 662 the necessary information for connecting to each other for 663 configuration, accounting, identification, and authentication 664 purposes. To summarize, at the completion of this stage both sides 665 have all the necessary protocol parameters such as timers, etc. The 666 Fl reference point may continue to operate during the association 667 phase and may be used to force a disassociation of an FE or CE. 668 Because the pre-association phase is out of scope, these details are 669 not discussed any further in this specification. The reader is 670 referred to the framework document [RFC3746] for a slightly more 671 detailed discussion. 673 4.2.2. Post-association 675 In this phase, the FE and CE components communicate with each other 676 using the ForCES protocol (PL over TML) as defined in this document. 677 There are three sub-phases: 679 o Association Setup Stage 681 o Established Stage 682 o Association Lost Stage 684 4.2.2.1. Association Setup Stage 686 The FE attempts to join the NE. The FE may be rejected or accepted. 687 Once granted access into the NE, capabilities exchange happens with 688 the CE querying the FE. Once the CE has the FE capability 689 information, the CE can offer an initial configuration (possibly to 690 restore state) and can query certain attributes within either an LFB 691 or the FE itself. 693 More details are provided in Section 4.4. 695 On successful completion of this stage, the FE joins the NE and is 696 moved to the Established Stage. 698 4.2.2.2. Established Stage 700 In this stage, the FE is continuously updated or queried. The FE may 701 also send asynchronous event notifications to the CE or synchronous 702 heartbeat notifications if programmed to do so. This stage continues 703 until a termination occurs, either due to loss of connectivity or due 704 to a termination initiated by either the CE or the FE. 706 Refer to the section on protocol scenarios, Section 4.4, for more 707 details. 709 4.2.2.3. Association Lost Stage 711 In this state, both or either the CE or FE declare the other side is 712 no longer associated. The disconnection could be initiated by either 713 party for administrative purposes but may also be driven by 714 operational reasons such as loss of connectivity. 716 A core LFB known as FE Protocol Object (FEPO) is defined (refer to 717 Appendix B and Section 7.3.1). FEPO defines various timers which can 718 be used in conjunction with traffic sensitive heartbeat mechanism 719 (Section 4.3.3) to detect loss of connectivity. 721 The loss of connectivity between TMLs does not indicate a loss of 722 association between respective PL layers. If the TML cannot repair 723 the transport loss before the programmed FEPO timer thresholds 724 associated with the FE is exceeded, then the association between the 725 respective PL layers will be lost. 727 FEPO defines several policies that can be programmed to define 728 behavior upon a detected loss of association. The FEPO's programmed 729 CE failover policy (refer to Section 8, Section 7.3.1, Section 4.3.3 730 and Appendix B) defines what takes place upon loss of association. 732 For this version of the protocol (as defined in this document), the 733 FE, upon re-association, MUST discard any state it has as invalid and 734 retrieve new state. This approach is motivated by a desire for 735 simplicity (as opposed to efficiency). 737 4.3. Protocol Mechanisms 739 Various semantics are exposed to the protocol users via the PL header 740 including: transaction capabilities, atomicity of transactions, two 741 phase commits, batching/parallelization, high availability and 742 failover as well as command pipelines. 744 The EM (Execute Mode) flag, AT (Atomic Transaction) flag, and TP 745 (Transaction Phase) flag as defined in the Common Header 746 (Section 6.1) are relevant to these mechanisms. 748 4.3.1. Transactions, Atomicity, Execution and Responses 750 In the master-slave relationship the CE instructs one or more FEs on 751 how to execute operations and how to report the results. 753 This section details the different modes of execution that a CE can 754 order the FE(s) to perform, as defined in Section 4.3.1.1. It also 755 describes the different modes a CE can ask the FE(s) to use for 756 formatting the responses after processing the operations as 757 requested. These modes relate to the transactional two phase 758 commitment operations. 760 4.3.1.1. Execution 762 There are 3 execution modes that can be requested for a batch of 763 operations spanning one or more LFB selectors (refer to 764 Section 7.1.5) in one protocol message. The EM flag defined in the 765 Common Header Section 6.1 selects the execution mode for a protocol 766 message, as below: 768 a. execute-all-or-none 770 b. execute-until-failure 772 c. continue-execute-on-failure 774 4.3.1.1.1. execute-all-or-none 776 When set to this mode of execution, independent operations in a 777 message MAY be targeted at one or more LFB selectors within an FE. 778 All these operations are executed serially and the FE MUST have no 779 execution failure for any of the operations. If any operation fails 780 to execute, then all the previous ones that have been executed prior 781 to the failure will need to be undone. I.e., there is rollback for 782 this mode of operation. 784 Refer to Section 4.3.1.2.2 for how this mode is used in cases of 785 transactions. In such a case, no operation is executed unless a 786 commit is issued by the CE. 788 Care should be taken on how this mode is used because a mis- 789 configuration could result in traffic losses. To add certainty to 790 the success of an operation, one should use this mode in a 791 transactional operation as described in Section 4.3.1.2.2 793 4.3.1.1.2. continue-execute-on-failure 795 If several independent operations are targeted at one or more LFB 796 selectors, execution continues for all operations at the FE even if 797 one or more operations fail. 799 4.3.1.1.3. execute-until-failure 801 In this mode all operations are executed on the FE sequentially until 802 the first failure. The rest of the operations are not executed but 803 operations already completed are not undone. I.e., there is no 804 rollback in this mode of operation. 806 4.3.1.2. Transaction and Atomicity 808 4.3.1.2.1. Transaction Definition 810 A transaction is defined as a collection of one or more ForCES 811 operations within one or more PL messages that MUST meet the ACIDity 812 properties [ACID], defined as: 814 Atomicity: In a transaction involving two or more discrete pieces 815 of information, either all of the pieces are committed 816 or none are. 818 Consistency: A transaction either creates a new and valid state of 819 data, or, if any failure occurs, returns all data to the 820 state it was in before the transaction was started. 822 Isolation: A transaction in process and not yet committed must 823 remain isolated from any other transaction. 825 Durability: Committed data is saved by the system such that, even in 826 the event of a failure and a system restart, the data is 827 available in its correct state. 829 There are cases where the CE knows exact memory and implementation 830 details of the FE such as in the case of an FE-CE pair from the same 831 vendor where the FE-CE pair is tightly coupled. In such a case, the 832 transactional operations may be simplified further by extra 833 computation at the CE. This view is not discussed further other than 834 to mention that it is not disallowed. 836 As defined above, a transaction is always atomic and MAY be 838 a. Within an FE alone 839 Example: updating multiple tables that are dependent on each 840 other. If updating one fails, then any that were already updated 841 must be undone. 843 b. Distributed across the NE 844 Example: updating table(s) that are inter-dependent across 845 several FEs (such as L3 forwarding related tables). 847 4.3.1.2.2. Transaction Protocol 849 By use of the execute mode, as defined in Section 4.3.1.1, the 850 protocol has provided a mechanism for transactional operations within 851 one stand-alone message. The 'execute-all-or-none' mode can meet the 852 ACID requirements. 854 For transactional operations of multiple messages within one FE or 855 across FEs, a classical transactional protocol known as Two Phase 856 Commit (2PC) [2PCREF] is supported by the protocol to achieve the 857 transactional operations utilizing Config messages (Section 7.6.1). 859 The COMMIT and TRCOMP operations in conjunction with the AT and the 860 TP flags in Common Header (Section 6.1) are provided for 2PC-based 861 transactional operations spanning multiple messages. 863 The AT flag, when set, indicates this message belongs to an Atomic 864 Transaction. All messages for a transaction operation must have the 865 AT flag set. If not set, it means the message is a stand-alone 866 message and does not participate in any transaction operation that 867 spans multiple messages. 869 The TP flag indicates the Transaction Phase this message belongs to. 871 There are four (4) possible phases for an transactional operation 872 known as: 874 SOT (Start of Transaction) 876 MOT (Middle of Transaction) 878 EOT (End of Transaction) 880 ABT (Abort) 882 The COMMIT operation is used by the CE to signal to the FE(s) to 883 commit a transaction. When used with an ABT TP flag, the COMMIT 884 operation signals the FE(s) to rollback (i.e un-COMMIT) a previously 885 committed transaction. 887 The TRCOMP operation is a small addition to the classical 2PC 888 approach. TRCOMP is sent by the CE to signal the FE(s) that the 889 transaction they have COMMITed is now over. This allows the FE(s) an 890 opportunity to clear state they may have kept around to perform a 891 rollback (if it became necessary). 893 A transaction operation is started with a message the TP flag is set 894 to Start of Transaction (SOT). Multi-part messages, after the first 895 one, are indicated by the Middle of Transaction flag (MOT). All 896 messages from the CE MUST set the AlwaysACK flag (Section 6) to 897 solicit responses from the FE(s). 899 Before the CE issues a commit (described further below) the FE MUST 900 only validate that the operation can be executed but not execute it. 902 Any failure notified by an FE causes the CE to abort the 903 transaction on all FEs involved in the transaction. This is 904 achieved by sending a Config message with an ABT flag and a COMMIT 905 operation. 907 If there are no failures by any participating FE, the transaction 908 commitment phase is signaled from the CE to the FE by an End of 909 Transaction (EOT) configuration message with a COMMIT operation. 911 The FE MUST respond to the CE's EOT message. There are two possible 912 failure scenarios in which the CE MUST abort the transaction (as 913 described above): 915 a. If any participating FE responds with a failure message in 916 relation to the transaction. 918 b. If no response is received from a participating FE within a 919 specified timeout. 921 If all participating FE(s) respond with a success indicator within 922 the expected time, then the CE MUST issue a TRCOMP operation to all 923 participating FEs. An FE MUST NOT respond to a TRCOMP. 925 Note that a transactional operation is generically atomic, therefore 926 it requires that the execute modes of all messages in a transaction 927 operation should always be kept the same and be set to 'execute-all- 928 or-none'. If the EM flag is set to other execute modes, it will 929 result in a transaction failure. 931 As noted above, a transaction may span multiple messages. It is up 932 to the CE to keep track of the different outstanding messages making 933 up a transaction. As an example, the correlator field could be used 934 to mark transactions and a sequence field to label the different 935 messages within the same atomic transaction, but this is out of scope 936 and up to implementations. 938 4.3.1.2.3. Recovery 940 Any of the participating FEs, or the CE, or the associations between 941 them, may fail after the EOT response message has been sent by the FE 942 but before the CE has received all the responses, e.g. if the EOT 943 response never reaches the CE. 945 In this protocol revision, as indicated in Section 4.2.2.3, an FE 946 losing an association would be required to get entirely new state 947 from the newly associated CE upon a re-association. Although this 948 approach is simplistic and provides likeliness of loosing datapath 949 traffic, it is a design choice to avoid the additional complexity of 950 managing graceful restarts. The HA mechanisms (Section 8) are 951 provided to allow for a continuous operation in case of FE failures. 953 Flexibility is provided on how to react when an FE looses 954 association. This is dictated by the CE Failover policy (refer to 955 Section 8 and Section 7.3). 957 4.3.1.2.4. Transaction Messaging Example 959 This section illustrates an example of how a successful two phase 960 commit between a CE and an FE would look like in the simple case. 962 FE PL CE PL 964 | | 965 | (1) Config, SOT,AT, EM=All-or-None, OP= SET/DEL,etc | 966 |<-----------------------------------------------------| 967 | | 968 | (2) ACKnowledge | 969 |----------------------------------------------------->| 970 | | 971 | (3) Config, MOT,AT, EM=All-or-None, OP= SET/DEL,etc | 972 |<-----------------------------------------------------| 973 | | 974 | (4) ACKnowledge | 975 |----------------------------------------------------->| 976 | | 977 | (5) Config, MOT,AT, EM=All-or-None, OP= SET/DEL,etc | 978 |<-----------------------------------------------------| 979 | | 980 | (6) ACKnowledge | 981 |----------------------------------------------------->| 982 . . 983 . . 984 . . 985 . . 986 | | 987 | (N) Config, EOT,AT, EM=All-or-None, OP= COMMIT | 988 |<-----------------------------------------------------| 989 | | 990 | (N+1)Config-response, ACKnowledge, OP=COMMIT-RESPONSE| 991 |----------------------------------------------------->| 992 | | 993 | (N+2) Config, OP=TRCOMP | 994 |<-----------------------------------------------------| 996 Figure 7: Example of a two phase commit 998 For the scenario illustrated above: 1000 o In step #1, the CE issues a Config message with an operation of 1001 choice like a DEL or SET. The transactional flag are set to 1002 indicate a Start of Transaction (SOT), Atomic Transaction (AT), 1003 execute-all-or-none. 1005 o The FE validates that it can execute the request successfully and 1006 then issues an acknowledgment back to the the CE in step #2. 1008 o In step #3, the same sort of construct as in step #1 is repeated 1009 by the CE with the transaction flag changed to Middle of 1010 Transaction(MOT). 1012 o The FE validates that it can execute the request successfully and 1013 then issues an acknowledgment back to the the CE in step #4. 1015 o The CE-FE exchange continues in the same manner until all the 1016 operations and their parameters are transferred to the FE. This 1017 happens in step #(N-1). 1019 o In step #N, the CE issues a commit. A commit is a config message 1020 with an operation of type COMMIT. The transactional flags are set 1021 to End of Transaction (EOT). Essentially, this is an "empty" 1022 message asking the FE to execute all the operations it has 1023 gathered since the beginning of the transaction (message #1). 1025 o The FE at this point executes the full transaction. It then 1026 issues an acknowledgment back to the the CE in step #(N+1) which 1027 contains a COMMIT-RESPONSE. 1029 o The CE in this case has the simple task of issuing a TRCOMP 1030 operation the the FE in step #(N+2) 1032 4.3.2. Scalability 1034 It is desirable that the PL not become the bottleneck when larger 1035 bandwidth pipes become available. To pick a hypothetical example in 1036 today's terms, if a 100Gbps pipe is available and there is sufficient 1037 work then the PL should be able to take advantage of this and use all 1038 of the 100Gbps pipe. Two mechanisms have been provided to achieve 1039 this. The first one is batching and the second one is a command 1040 pipeline. 1042 Batching is the ability to send multiple commands (such as Config) in 1043 one Protocol Data Unit (PDU). The size of the batch will be affected 1044 by, amongst other things, the path MTU. The commands may be part of 1045 the same transaction or may be part of unrelated transactions that 1046 are independent of each other. 1048 Command pipelining allows for pipelining of independent transactions 1049 which do not affect each other. Each independent transaction could 1050 consist of one or more batches. 1052 4.3.2.1. Batching 1054 There are several batching levels at different protocol hierarchies. 1056 o multiple PL PDUs can be aggregated under one TML message 1057 o multiple LFB classes and instances (as indicated in the LFB 1058 selector) can be addressed within one PL PDU 1060 o Multiple operations can be addressed to a single LFB class and 1061 instance 1063 4.3.2.2. Command Pipelining 1065 The protocol allows any number of messages to be issued by the CE 1066 before the corresponding acknowledgments (if requested) have been 1067 returned by the FE. Hence pipelining is inherently supported by the 1068 protocol. Matching responses with requests messages can be done 1069 using the correlator field in the message header. 1071 4.3.3. Heartbeat Mechanism 1073 Heartbeats (HB) between FEs and CEs are traffic sensitive. An HB is 1074 sent only if no PL traffic is sent between the CE and FE within a 1075 configured interval. This has the effect of reducing the amount of 1076 HB traffic in the case of busy PL periods. 1078 An HB can be sourced by either the CE or FE. When sourced by the CE, 1079 a response can be requested (similar to the ICMP ping protocol). The 1080 FE can only generate HBs in the case of being configured to do so by 1081 the CE. Refer to Section 7.3.1 and Section 7.10 for details. 1083 4.3.4. FE Object and FE Protocol LFBs 1085 All PL messages operate on LFB constructs, as this provides more 1086 flexibility for future enhancements. This means that maintenance and 1087 configurability of FEs, NE, as well as the ForCES protocol itself 1088 must be expressed in terms of this LFB architecture. For this reason 1089 special LFBs are created to accommodate this need. 1091 In addition, this shows how the ForCES protocol itself can be 1092 controlled by the very same type of structures (LFBs) it uses to 1093 control functions such as IP forwarding, filtering, etc. 1095 To achieve this, the following specialized LFBs are introduced: 1097 o FE Protocol LFB which is used to control the ForCES protocol. 1099 o FE Object LFB which is used to control attributes relative to the 1100 FE itself. Such attributes include FEState [FE-MODEL], vendor, 1101 etc. 1103 These LFBs are detailed in Section 7.3. 1105 4.4. Protocol Scenarios 1107 This section provides a very high level description of sample message 1108 sequences between a CE and FE. For protocol message encoding refer 1109 to Section 6.1 and for the semantics of the protocol refer to 1110 Section 4.3. 1112 4.4.1. Association Setup State 1114 The associations among CEs and FEs are initiated via Association 1115 setup message from the FE. If a setup request is granted by the CE, 1116 a successful setup response message is sent to the FE. If CEs and 1117 FEs are operating in an insecure environment then the security 1118 associations have to be established between them before any 1119 association messages can be exchanged. The TML will take care of 1120 establishing any security associations. 1122 This is typically followed by capability query, topology query, etc. 1123 When the FE is ready to start forwarding data traffic, it sends an FE 1124 UP Event message to the CE. When the CE is ready, it responds by 1125 enabling the FE by setting the FEStatus to Adminup (Refer to 1126 [FE-MODEL] for details). This indicates to the FE to start 1127 forwarding data traffic. At this point the association establishment 1128 is complete. These sequences of messages are illustrated in the 1129 Figure 8 below. 1131 FE PL CE PL 1133 | | 1134 | Asso Setup Req | 1135 |---------------------->| 1136 | | 1137 | Asso Setup Resp | 1138 |<----------------------| 1139 | | 1140 | LFBx Query capability | 1141 |<----------------------| 1142 | | 1143 | LFBx Query Resp | 1144 |---------------------->| 1145 | | 1146 | FEO Query (Topology) | 1147 |<----------------------| 1148 | | 1149 | FEO Query Resp | 1150 |---------------------->| 1151 | | 1152 | FEO UP Event | 1153 |---------------------->| 1154 | | 1155 | Config FEO Adminup | 1156 |<----------------------| 1157 | | 1158 | FEO Config-Resp | 1159 |---------------------->| 1160 | | 1162 Figure 8: Message exchange between CE and FE to establish an NE 1163 association 1165 On successful completion of this state, the FE joins the NE. 1167 4.4.2. Association Established state or Steady State 1169 In this state, the FE is continuously updated or queried. The FE may 1170 also send asynchronous event notifications to the CE, synchronous 1171 heartbeat messages, or packet redirect message to the CE. This 1172 continues until a termination (or deactivation) is initiated by 1173 either the CE or FE. Figure 9 below, helps illustrate this state. 1175 FE PL CE PL 1177 | | 1178 | Heart Beat | 1179 |<---------------------------->| 1180 | | 1181 | Heart Beat | 1182 |----------------------------->| 1183 | | 1184 | Config-set LFBy (Event sub.) | 1185 |<-----------------------------| 1186 | | 1187 | Config Resp LFBy | 1188 |----------------------------->| 1189 | | 1190 | Config-set LFBx Attr | 1191 |<-----------------------------| 1192 | | 1193 | Config Resp LFBx | 1194 |----------------------------->| 1195 | | 1196 |Config-Query LFBz (Stats) | 1197 |<--------------------------- -| 1198 | | 1199 | Query Resp LFBz | 1200 |----------------------------->| 1201 | | 1202 | FE Event Report | 1203 |----------------------------->| 1204 | | 1205 | Config-Del LFBx Attr | 1206 |<-----------------------------| 1207 | | 1208 | Config Resp LFBx | 1209 |----------------------------->| 1210 | | 1211 | Packet Redirect LFBx | 1212 |----------------------------->| 1213 | | 1214 | Heart Beat | 1215 |<-----------------------------| 1216 . . 1217 . . 1218 | | 1220 Figure 9: Message exchange between CE and FE during steady-state 1221 communication 1223 Note that the sequence of messages shown in the figure serve only as 1224 examples and the message exchange sequences could be different from 1225 what is shown in the figure. Also, note that the protocol scenarios 1226 described in this section do not include all the different message 1227 exchanges that would take place during failover. That is described 1228 in the HA section (Section 8) . 1230 5. TML Requirements 1232 The requirements below are expected to be delivered by the TML. This 1233 text does not define how such mechanisms are delivered. As an 1234 example they could be defined to be delivered via hardware or between 1235 2 or more TML processes on different CEs or FEs in protocol level 1236 schemes. 1238 Each TML must describe how it contributes to achieving the listed 1239 ForCES requirements. If for any reason a TML does not provide a 1240 service listed below a justification needs to be provided. 1242 1. Reliability 1243 As defined by RFC 3654, section 6 #6. 1245 2. Security 1246 TML provides security services to the ForCES PL. A TML layer 1247 should support the following security services and describe how 1248 they are achieved. 1250 * Endpoint authentication of FE and CE 1252 * Message authentication 1254 * Confidentiality service 1256 3. Congestion control 1257 The congestion control scheme used needs to be defined. The 1258 congestion control mechanism defined by the TML should prevent 1259 the FE from being overloaded by the CE or the CE from being 1260 overwhelmed by traffic from the FE. Additionally, the 1261 circumstances under which notification is sent to the PL to 1262 notify it of congestion must be defined. 1264 4. Uni/multi/broadcast addressing/delivery, if any 1265 If there is any mapping between PL and TML level uni/multi/ 1266 broadcast addressing it needs to be defined. 1268 5. HA decisions 1269 It is expected that availability of transport links is the TML's 1270 responsibility. However, based upon its configuration, the PL 1271 may wish to participate in link failover schemes and therefore 1272 the TML must support this capability. 1273 Please refer to Section 8 for details. 1275 6. Encapsulations used 1276 Different types of TMLs will encapsulate the PL messages on 1277 different types of headers. The TML needs to specify the 1278 encapsulation used. 1280 7. Prioritization 1281 It is expected that the TML will be able to handle up to 8 1282 priority levels needed by the PL and will provide preferential 1283 treatment. 1284 While the TML needs to define how this is achieved, it should be 1285 noted that the requirement for supporting up to 8 priority levels 1286 does not mean that the underlying TML MUST be capable of 1287 providing up to 8 actual priority levels. In the event that the 1288 underlying TML layer does not have support for 8 priority levels, 1289 the supported priority levels should be divided between the 1290 available TML priority levels. For example, if the TML only 1291 supports 2 priority levels, the 0-3 could go in one TML priority 1292 level, while 4-7 could go in the other. 1293 The TML MUST NOT reorder config packets with the same priority. 1295 8. Protection against DoS attacks 1296 As described in RFC 3654, section 6 1298 5.1. TML Parameterization 1300 It is expected that it should be possible to use a configuration 1301 reference point, such as the FEM or the CEM, to configure the TML. 1303 Some of the configured parameters may include: 1305 o PL ID 1307 o Connection Type and associated data. For example if a TML uses 1308 IP/TCP/UDP, then parameters such as TCP and UDP port and IP 1309 addresses need to be configured. 1311 o Number of transport connections 1313 o Connection capability, such as bandwidth, etc. 1315 o Allowed/supported connection QoS policy (or congestion control 1316 policy) 1318 6. Message Encapsulation 1320 All PL PDUs start with a common header [Section 6.1] followed by a 1321 one or more TLVs [Section 6.2] which may nest other TLVs 1322 [Section 6.2.1]. All fields are in network byte order. 1324 6.1. Common Header 1326 0 1 2 3 1327 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 1328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1329 |version| rsvd | Message Type | Length | 1330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 | Source ID | 1332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1333 | Destination ID | 1334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1335 | Correlator[32:63] | 1336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1337 | Correlator[0:31] | 1338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1339 | Flags | 1340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 Figure 10: Common Header 1344 The message is 32 bit aligned. 1346 Version (4 bit): 1347 Version number. Current version is 1. 1349 rsvd (4 bit): 1350 Unused at this point. A receiver should not interpret this 1351 field. Senders MUST set it to zero and receivers MUST ignore 1352 this field. 1354 Message Type (8 bits): 1355 Commands are defined in Section 7. 1357 Length (16 bits): 1358 length of header + the rest of the message in DWORDS (4 byte 1359 increments). 1361 Source ID (32 bit): 1363 Dest ID (32 bit): 1365 * Each of the source and destination IDs are 32 bit IDs which 1366 are unique NE-wide and which identify the termination points 1367 of a ForCES PL message. 1369 * IDs allow multi/broad/unicast addressing with the following 1370 approach: 1372 a. A split address space is used to distinguish FEs from 1373 CEs. Even though in a large NE there are typically two 1374 or more orders of magnitude more FEs than CEs, the 1375 address space is split uniformly for simplicity. 1377 b. The address space allows up to 2^30 (over a billion) CEs 1378 and the same amount of FEs. 1380 0 1 2 3 1381 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 1382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1383 |TS | sub-ID | 1384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 Figure 11: ForCES ID Format 1388 c. The 2 most significant bits called Type Switch (TS) are 1389 used to split the ID space as follows: 1391 TS Corresponding ID range Assignment 1392 -- ---------------------- ---------- 1393 0b00 0x00000000 to 0x3FFFFFFF FE IDs (2^30) 1394 0b01 0x40000000 to 0x7FFFFFFF CE IDs (2^30) 1395 0b10 0x80000000 to 0xBFFFFFFF reserved 1396 0b11 0xC0000000 to 0xFFFFFFEF multicast IDs (2^30 - 16) 1397 0b11 0xFFFFFFF0 to 0xFFFFFFFC reserved 1398 0b11 0xFFFFFFFD all CEs broadcast 1399 0b11 0xFFFFFFFE all FEs broadcast 1400 0b11 0xFFFFFFFF all FEs and CEs (NE) broadcast 1402 Figure 12: Type Switch ID Space 1404 * Multicast or broadcast IDs are used to group endpoints (such 1405 as CEs and FES). As an example one could group FEs in some 1406 functional group, by assigning a multicast ID. Likewise, 1407 subgroups of CEs that act, for instance, in a back-up mode 1408 may be assigned a multicast ID to hide them from the FE. 1410 + Multicast IDs can be used for both source or destination 1411 IDs. 1413 + Broadcast IDs can be used only for destination IDs. 1415 * This document does not discuss how a particular multicast ID 1416 is associated to a given group though it could be done via 1417 configuration process. The list of IDs an FE owns or is part 1418 of are listed on the FE Object LFB. 1420 Correlator (64 bits) 1421 This field is set by the CE to correlate ForCES Request Messages 1422 with the corresponding Response messages from the FE. 1423 Essentially it is a cookie. The correlator is handled 1424 transparently by the FE, i.e., for a particular Request message 1425 the FE MUST assign the same correlator value in the corresponding 1426 Response message. In the case where the message from the CE does 1427 not elicit a response, this field may not be useful. 1429 The correlator field could be used in many implementations 1430 specific ways by the CE. For example, the CE could split the 1431 correlator into a 32-bit transactional identifier and 32-bit 1432 message sequence identifier. Another example is a 64-bit pointer 1433 to a context block. All such implementation specific use of the 1434 correlator is outside the scope of this specification. 1436 Whenever the correlator field is not relevant, because no message 1437 is expected, the correlator field is set to 0. 1439 Flags(32 bits): 1440 Identified so far: 1442 0 1 2 3 1443 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 1444 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1445 | | | | | | | | 1446 |ACK| Pri |Rsr |EM |A|TP | Reserved | 1447 | | | vd. | |T| | | 1448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1450 Figure 13: Header Flags 1452 - ACK: ACK indicator (2 bit) 1453 The ACK indicator flag is only used by the CE when sending a 1454 Config Message (Section 7.6.1) or a HB message (Section 7.10) 1455 to indicate to the message receiver whether or not a response 1456 is required by the sender. Note that for all other messages 1457 than the Config Message or the HB Message this flag MUST be 1458 ignored. 1460 The flag values are defined as below: 1462 'NoACK' (0b00) - to indicate that the message receiver 1463 MUST not send any response message back to this message 1464 sender. 1466 'SuccessACK'(0b01) - to indicate the message receiver 1467 MUST send a response message back only when the message 1468 has been successfully processed by the receiver. 1470 'FailureACK'(0b10) - to indicate the message receiver 1471 MUST send a response message back only when there is 1472 failure by the receiver in processing (executing) the 1473 message. In other words, if the message can be processed 1474 successfully, the sender will not expect any response 1475 from the receiver. 1477 'AlwaysACK' (0b11) - to indicate the message receiver 1478 MUST send a response message. 1480 Note that in above definitions, the term success implies a 1481 complete execution without any failure of the message. 1482 Anything else than a complete successful execution is defined 1483 as a failure for the message processing. As a result, for 1484 the execution modes (defined in Section 4.3.1.1) like 1485 execute-all-or-none, execute-until-failure, and continue- 1486 execute-on-failure, if any single operation among several 1487 operations in the same message fails, it will be treated as a 1488 failure and result in a response if the ACK indicator has 1489 been set to 'FailureACK' or 'AlwaysACK'. 1491 Also note that, other than in Config and HB Messages, 1492 requirements for responses of messages are all given in a 1493 default way rather than by ACK flags. The default 1494 requirements of these messages and the expected responses are 1495 summarized below. Detailed descriptions can be found in the 1496 individual message definitions: 1498 + Association Setup Message always expects a response. 1500 + Association Teardown Message, and Packet Redirect 1501 Message, never expect responses. 1503 + Query Message always expects a response. 1505 + Response message never expects further responses. 1507 - Pri: Priority (3 bits) 1508 ForCES protocol defines 8 different levels of priority (0-7). 1509 The priority level can be used to distinguish between 1510 different protocol message types as well as between the same 1511 message type. The higher the priority value, the more 1512 important the PDU is. For example, the REDIRECT packet 1513 message could have different priorities to distinguish 1514 between routing protocols packets and ARP packets being 1515 redirected from FE to CE. The Normal priority level is 1. 1516 The different priorities imply messages could be re-ordered; 1517 however, re-ordering is undesirable when it comes to a set of 1518 messages within a transaction and caution should be exercised 1519 to avoid this from happening. 1521 - EM: Execution Mode (2 bits) 1522 There are 3 execution modes refer to Section 4.3.1.1 for 1523 details. 1525 Reserved..................... (0b00) 1527 `execute-all-or-none` ....... (0b01) 1529 `execute-until-failure` ..... (0b10) 1531 `continue-execute-on-failure` (0b11) 1533 - AT: Atomic Transaction (1 bit) 1534 This flag indicates if the message is stand-alone message or 1535 one of multiple messages that belongs to 2PC transaction 1536 operations. See Section 4.3.1.2.2 for details. 1538 Stand-alone message ......... (0b0) 1540 2PC transaction message ..... (0b1) 1542 - TP: Transaction Phase (2 bits) 1543 A message from the CE to the FE within a transaction could be 1544 indicative of the different phases the transaction is in. 1545 Refer to Section 4.3.1.2.2 for details. 1547 SOT (start of transaction) ..... (0b00) 1549 MOT (Middle of transaction) .... (0b01) 1551 EOT (end of transaction) ........(0b10) 1553 ABT (abort) .....................(0b11) 1555 6.2. Type Length Value (TLV) Structuring 1557 TLVs are extensively used by the ForCES protocol. TLVs have some 1558 very nice properties which make them a good candidate for encoding 1559 the XML definitions of the LFB class model. These are: 1561 o Providing for binary type-value encoding that is close to the XML 1562 string tag-value scheme. 1564 o Allowing for fast generalized binary-parsing functions. 1566 o Allowing for forward and backward tag compatibility. This is 1567 equivalent to the XML approach i.e old applications can ignore new 1568 TLVs and newer applications can ignore older TLVs. 1570 0 1 2 3 1571 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 1572 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1573 | TLV Type | TLV Length | 1574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1575 | Value (Essentially the TLV Data) | 1576 ~ ~ 1577 ~ ~ 1578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 Figure 14: TLV Representation 1582 TLV Type (16): 1583 The TLV type field is two octets, and semantically 1584 indicates the type of data encapsulated within the 1585 TLV. 1587 TLV Length (16): 1588 The TLV length field is two octets, and includes the 1589 length of the TLV type (2 octets), TLV Length (2 1590 octets), and the length of the TLV data found in the 1591 value field, in octets. Note that this length is 1592 the actual length of the value, before any padding 1593 for alignment is added. 1595 TLV Value (variable): 1596 The TLV value field carries the data. For 1597 extensibility, the TLV value may in fact be a TLV. 1598 Padding is required when the length is not a 1599 multiple of 32 bits, and is the minimum number of 1600 bytes required to bring the TLV to a multiple of 32 1601 bits. The length of the value before padding is 1602 indicated by the TLV Length field. Note: The value 1603 field could be empty which implies the minimal 1604 length a TLV could be is 4 (length of "T" field and 1605 length of "L" field). 1607 6.2.1. Nested TLVs 1609 TLV values can be other TLVs. This provides the benefits of protocol 1610 flexibility (being able to add new extensions by introducing new TLVs 1611 when needed). The nesting feature also allows for a conceptual 1612 optimization with the XML LFB definitions to binary PL representation 1613 (represented by nested TLVs). 1615 6.2.2. Scope of the T in TLV 1617 The "Type" values in the TLV are global in scope. This means that 1618 wherever TLVs occur in the PDU, a specific Type value refers to the 1619 same Type of TLV. This is a design choice that was made to ease 1620 debugging of the protocol. 1622 6.3. ILV 1624 A slight variation of the TLV known as the ILV. This sets the type 1625 ("T") to be a 32-bit local index that refers to a ForCES element ID. 1626 (refer to Section 6.4.1). The Length part of the ILV is fixed at 32 1627 bits. 1629 0 1 2 3 1630 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 1631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1632 | Identifier | 1633 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1634 | Length | 1635 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1636 | Value | 1637 . . 1638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1640 Figure 15: ILV Representation 1642 It should be noted that the "I" values are of local scope and are 1643 defined by the data declarations from the LFB definition. Refer to 1644 Section 7.1.8 for discussions on usage of ILVs. 1646 6.4. Important Protocol encapsulations 1648 In this section, we review a few encapsulation concepts that are used 1649 by the ForCES protocol for its operations. 1651 We briefly re-introduce two concepts, Paths and Keys, from the model 1652 draft [FE-MODEL] in order to provide context. The reader is referred 1653 to [FE-MODEL] for a lot of the finer details. 1655 For readability reasons, we introduce the encapsulation schemes that 1656 are used to carry content in a protocol message, namely FULLDATA, 1657 SPARSEDATA, and RESULT TLVs. 1659 6.4.1. Paths 1661 The model draft [FE-MODEL] defines an XML-based language that allows 1662 for a formal definition of LFBs. This is similar to the relationship 1663 between ASN.1 and SNMP MIB definition (MIB being analogous to the LFB 1664 and ASN.1 being analogous to the XML model language). Any entity 1665 that the CE configures on an FE MUST be formally defined in an LFB. 1666 These entities could be scalars (e.g., a 32-bit IPv4 address) or 1667 vectors (such as a nexthop table). Each entity within the LFB is 1668 given a numeric 32-bit identifier known as an "element id". This 1669 scheme allows the attribute to be "addressed" in a protocol 1670 construct. 1672 These addressable entities could be hierarchical (e.g., a table 1673 column or a cell within a table row). In order to address 1674 hierarchical data, the concept of a path is introduced by the model 1675 [FE-MODEL]. A path is a series of 32-bit element IDs which are 1676 typically presented in a dot-notation (e.g., 1.2.3.4). Section 1677 (Section 7) formally defines how paths are used to reference data 1678 that is being encapsulated within a protocol message. 1680 6.4.2. Keys 1682 The model draft [FE-MODEL] defines two ways to address table rows. 1683 The standard/common mechanism is to allow table rows to be referenced 1684 by a 32-bit index. The secondary mechanism is via Keys which allow 1685 for content addressing. An example key is a multi-field content key 1686 that uses the IP address and prefix length to uniquely reference an 1687 IPv4 routing table row. In essence, while the common scheme to 1688 address a table row is via its table index, a table row's path could 1689 be derived from a key. The KEYINFO TLV (Section 7) is used to carry 1690 the data that is used to do the lookup. 1692 6.4.3. DATA TLVs 1694 Data from or to the FE is carried in two types of TLVs: FULLDATA TLV 1695 and SPARSEDATA TLV. Responses on operations executed by the FE are 1696 carried in RESULT TLVs. 1698 In FULLDATA TLV, the data is encoded in such a way that a receiver of 1699 such data, by virtue of being armed with knowledge of the path and 1700 the LFB definition, can infer or correlate the TLV "Value" contents. 1701 This is essentially an optimization that helps reduce the amount of 1702 description required for the transported data in the protocol 1703 grammar. Refer to Appendix C for an example of FULLDATA TLVs. 1705 A number of operations in ForCES will need to reference optional data 1706 within larger structures. The SPARSEDATA TLV encoding is provided to 1707 make it easier to encapsulate optionally appearing data elements. 1708 Refer to Appendix C for an example of SPARSEDATA TLV. 1710 RESULT TLVs carry responses back from the FE based on a config issued 1711 by the CE. Refer to Appendix C for examples of RESULT TLVs and 1712 Section 7.1.7 for layout. 1714 6.4.4. Addressing LFB entities 1716 Section 6.4.1 and Section 6.4.2 discuss how to target an entity 1717 within an LFB. However, the addressing mechanism used requires that 1718 an LFB type and instance is selected first. The LFB Selector is used 1719 to select an LFB type and instance being targeted. Section 1720 (Section 7) goes into more details; for our purpose, we illustrate 1721 this concept using Figure 16 below. More examples of layouts can be 1722 found reading further into the text (Example: Figure 21). 1724 main hdr (Message type: example "config") 1725 | 1726 | 1727 | 1728 +- T = LFBselect 1729 | 1730 +-- LFBCLASSID (unique per LFB defined) 1731 | 1732 | 1733 +-- LFBInstance (runtime configuration) 1734 | 1735 +-- T = An operation TLV describes what we do to an entity 1736 | //Refer to the OPER-TLV values enumerated below 1737 | //the TLVs that can be used for operations 1738 | 1739 | 1740 +--+-- one or more path encodings to target an entity 1741 | // Refer to the discussion on keys and paths 1742 | 1743 | 1744 +-- The associated data, if any, for the entity 1745 // Refer to discussion on FULL/SPARSE DATA TLVs 1747 Figure 16: Entity Addressing 1749 7. Protocol Construction 1751 A protocol layer PDU consists of a Common Header (defined in Section 1752 Section 6.1 ) and a message body. The Common Header is followed by a 1753 message-type-specific message body. Each message body is formed from 1754 one or more top-level TLVs. A top-level TLV may contain one or more 1755 sub-TLVs; these sub-TLVs are described in this document as OPER-TLVs, 1756 because they describe an operation to be done. 1758 +--------------+--------------+---------------------+---------------+ 1759 | Message Name | Top-Level | OPER-TLV(s) | Reference | 1760 | | TLV | | | 1761 +--------------+--------------+---------------------+---------------+ 1762 | Association | (LFBselect)* | REPORT | Section 7.5.2 | 1763 | Setup | | | | 1764 | | | | | 1765 | Association | ASRresult | none | Section 7.5.2 | 1766 | Setup | | | | 1767 | Response | | | | 1768 | | | | | 1769 | Association | ASTreason | none | Section 7.5.3 | 1770 | Teardown | | | | 1771 | | | | | 1772 | Config | (LFBselect)+ | (SET | SET-PROP | | Section 7.6.1 | 1773 | | | DEL | COMMIT | | | 1774 | | | TRCOMP)+ | | 1775 | | | | | 1776 | Config | LFBselect | (SET-RESPONSE | | Section 7.6.2 | 1777 | Response | | SET-PROP-RESPONSE | | | 1778 | | | DEL-RESPONSE | | | 1779 | | | COMMIT-RESPONSE)+ | | 1780 | | | | | 1781 | Query | (LFBselect)+ | (GET | GET-PROP)+ | Section 7.7.1 | 1782 | | | | | 1783 | Query | (LFBselect)+ | (GET-RESPONSE | | Section 7.7.2 | 1784 | Response | | GET-PROP-RESPONSE)+ | | 1785 | | | | | 1786 | Event | LFBselect | REPORT | Section 7.8 | 1787 | Notification | | | | 1788 | | | | | 1789 | Packet | REDIRECT-TLV | none | Section 7.9 | 1790 | Redirect | | | | 1791 | | | | | 1792 | Heartbeat | none | none | Section 7.10 | 1793 +--------------+--------------+---------------------+---------------+ 1795 Table 1 1797 The different messages are illustrated in Table 1. The different 1798 message type numerical values are defined in Appendix A.1. All the 1799 TLVs values are defined in Appendix A.2. 1801 An LFBselect TLV (refer to Section 7.1.5) contains the LFB Classid 1802 and LFB Instance being referenced as well as the OPER-TLV(s) being 1803 applied to that reference. 1805 Each type of OPER-TLV is constrained as to how it describes the paths 1806 and selectors of interest. The following BNF describes the basic 1807 structure of an OPER-TLV and Table 2 gives the details for each type 1809 OPER-TLV := 1*PATH-DATA-TLV 1810 PATH-DATA-TLV := PATH [DATA] 1811 PATH := flags IDcount IDs [SELECTOR] 1812 SELECTOR := KEYINFO-TLV 1813 DATA := FULLDATA-TLV / SPARSEDATA-TLV / RESULT-TLV / 1814 1*PATH-DATA-TLV 1815 KEYINFO-TLV := KeyID FULLDATA-TLV 1816 FULLDATA-TLV := encoded data element which may nest 1817 further FULLDATA-TLVs 1818 SPARSEDATA-TLV := encoded data that may have optionally 1819 appearing elements 1820 RESULT-TLV := Holds result code and optional FULLDATA-TLV 1822 Figure 17: BNF of OPER-TLV 1824 o PATH-DATA-TLV identifies the exact element targeted and may have 1825 zero or more paths associated with it. The last PATH-DATA-TLV in 1826 the case of nesting of paths via the DATA construct in the case of 1827 SET, SET-PROP requests and GET-RESPONSE/GET-PROP-RESPONSE is 1828 terminated by encoded data or response in the form of either 1829 FULLDATA-TLV or SPARSEDATA-TLV or RESULT TLV. 1831 o PATH provides the path to the data being referenced. 1833 * flags (16 bits) are used to further refine the operation to be 1834 applied on the Path. More on these later. 1836 * IDcount(16 bit): count of 32 bit IDs 1838 * IDs: zero or more 32bit IDs (whose count is given by IDcount) 1839 defining the main path. Depending on the flags, IDs could be 1840 field IDs only or a mix of field and dynamic IDs. Zero is used 1841 for the special case of using the entirety of the containing 1842 context as the result of the path. 1844 o SELECTOR is an optional construct that further defines the PATH. 1845 Currently, the only defined selector is the KEYINFO-TLV, used for 1846 selecting an array entry by the value of a key field. The 1847 presence of a SELECTOR is correct only when the flags also 1848 indicate its presence. A mismatch is a protocol format error. 1850 o A KEYINFO TLV contains information used in content keying. 1852 * A KeyID is used in a KEYINFO TLV. It indicates which key for 1853 the current array is being used as the content key for array 1854 entry selection. 1856 * The key's data is the data to look for in the array, in the 1857 fields identified by the key field. The information is encoded 1858 according to the rules for the contents of a FULLDATA-TLV, and 1859 represent the field or fields which make up the key identified 1860 by the KeyID. 1862 o DATA may contain a FULLDATA-TLV, SPARSEDATA-TLV, a RESULT TLV or 1 1863 or more further PATH-DATA selection. FULLDATA and SPARSEDATA are 1864 only allowed on SET or SET-PROP requests, or on responses which 1865 return content information (GET-RESPONSE for example). PATH-DATA 1866 may be included to extend the path on any request. 1868 * Note: Nested PATH-DATA TLVs are supported as an efficiency 1869 measure to permit common subexpression extraction. 1871 * FULLDATA and SPARSEDATA contain "the data" whose path has been 1872 selected by the PATH. Refer to Section 7.1 for details. 1874 * The following table summarizes the applicability and 1875 restrictions of the FULL/SPARSEDATA TLV and the RESULT TLV to 1876 the OPER-TLVs. 1878 +-------------------+-------------------------------+---------------+ 1879 | OPER-TLV | DATA TLV | RESULT TLV | 1880 +-------------------+-------------------------------+---------------+ 1881 | SET | (FULLDATA-TLV | | none | 1882 | | SPARSEDATA-TLV)+ | | 1883 | | | | 1884 | SET-PROP | (FULLDATA-TLV | | none | 1885 | | SPARSEDATA-TLV)+ | | 1886 | | | | 1887 | SET-RESPONSE | none | (RESULT-TLV)+ | 1888 | | | | 1889 | SET-PROP-RESPONSE | none | (RESULT-TLV)+ | 1890 | | | | 1891 | DEL | (FULLDATA-TLV | | none | 1892 | | SPARSEDATA-TLV)+ | | 1893 | | | | 1894 | DEL-RESPONSE | none | (RESULT-TLV)+ | 1895 | | | | 1896 | GET | none | none | 1897 | | | | 1898 | GET-PROP | none | none | 1899 | | | | 1900 | GET-RESPONSE | (FULLDATA-TLV)+ | (RESULT-TLV)* | 1901 | | | | 1902 | GET-PROP-RESPONSE | (FULLDATA-TLV)+ | (RESULT-TLV)* | 1903 | | | | 1904 | REPORT | (FULLDATA-TLV)+ | none | 1905 | | | | 1906 | COMMIT | none | none | 1907 | | | | 1908 | COMMIT-RESPONSE | none | (RESULT-TLV)+ | 1909 | | | | 1910 | TRCOMP | none | none | 1911 +-------------------+-------------------------------+---------------+ 1913 Table 2 1915 o RESULT contains the indication of whether the individual SET or 1916 SET-PROP succeeded. RESULT TLV is included on the assumption that 1917 individual parts of a SET request can succeed or fail separately. 1919 In summary this approach has the following characteristic: 1921 o There can be one or more LFB class ID and instance ID combination 1922 targeted in a message (batch) 1924 o There can one or more operations on an addressed LFB class ID/ 1925 instance ID combination (batch) 1927 o There can be one or more path targets per operation (batch) 1929 o Paths may have zero or more data values associated (flexibility 1930 and operation specific) 1932 It should be noted that the above is optimized for the case of a 1933 single LFB class ID and instance ID targeting. To target multiple 1934 instances within the same class, multiple LFBselects are needed. 1936 7.1. Discussion on encoding 1938 Section 6.4.3 discusses the two types of DATA encodings (FULLDATA and 1939 SPARSEDATA TLV) and the justifications for their existence. In this 1940 section we explain how they are encoded. 1942 7.1.1. Data Packing Rules 1944 The scheme for encoding data used in this doc adheres to the 1945 following rules: 1947 o The Value ("V" of TLV) of FULLDATA TLV will contain the data being 1948 transported. This data will be as was described in the LFB 1949 definition. 1951 o Variable sized data within a FULLDATA TLV will be encapsulated 1952 inside another FULLDATA TLV inside the V of the outer TLV. For 1953 example of such a setup refer to Appendix C and Appendix D 1955 o In the case of FULLDATA TLVs: 1957 * When a table is referred to in the PATH (IDs) of a PATH-DATA- 1958 TLV, then the FULLDATA's "V" will contain that table's row 1959 content prefixed by its 32 bit index/subscript. On the other 1960 hand, when PATH flags are 00, the PATH may contain an index 1961 pointing to a row in table; in such a case, the FULLDATA's "V" 1962 will only contain the content with the index in order to avoid 1963 ambiguity. 1965 7.1.2. Path Flags 1967 The following flags are currently defined: 1969 o SELECTOR Bit: F_SELKEY indicates that a KEY Selector is present 1970 following this path information, and should be considered in 1971 evaluating the path. 1973 7.1.3. Relation of operational flags with global message flags 1975 Global flags, such as the execution mode and the atomicity indicators 1976 defined in the header, apply to all operations in a message. Global 1977 flags provide semantics that are orthogonal to those provided by the 1978 operational flags, such as the flags defined in Path Data. The scope 1979 of operational flags is restricted to the operation. 1981 7.1.4. Content Path Selection 1983 The KEYINFO TLV describes the KEY as well as associated KEY data. 1984 KEYs, used for content searches, are restricted and described in the 1985 LFB definition. 1987 7.1.5. LFBselect-TLV 1989 The LFBselect TLV is an instance of a TLV as defined in Section 6.2. 1990 The definition is as below: 1992 0 1 2 3 1993 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 1994 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1995 | Type = LFBselect | Length | 1996 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1997 | LFB Class ID | 1998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1999 | LFB Instance ID | 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2001 | OPER-TLV | 2002 . . 2003 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2004 ~ ... ~ 2005 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2006 | OPER-TLV | 2007 . . 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2010 Figure 18: PL PDU layout 2012 Type: 2013 The type of the TLV is "LFBselect" 2015 Length: 2016 Length of the TLV including the T and L fields, in octets. 2018 LFB Class ID: 2019 This field uniquely recognizes the LFB class/type. 2021 LFB Instance ID: 2022 This field uniquely identifies the LFB instance. 2024 OPER-TLV: 2025 It describes an operation nested in the LFBselect TLV. Note that 2026 usually there SHOULD be at least one OPER-TLV present for an LFB 2027 select TLV, but for the Association Setup Message defined in 2028 Section 7.5.1 where the OPER-TLV is optional. 2030 7.1.6. OPER-TLV 2032 The OPER-TLV is a place holder in the grammar for TLVs that define 2033 operations. The different types are defined in Table 3, below. 2035 +-------------------+--------+--------------------------------------+ 2036 | OPER-TLV | TLV | Comments | 2037 | | "Type" | | 2038 +-------------------+--------+--------------------------------------+ 2039 | SET | 0x0001 | From CE to FE. Used to create or | 2040 | | | add or update attributes | 2041 | | | | 2042 | SET-PROP | 0x0002 | From CE to FE. Used to create or | 2043 | | | add or update attribute properties | 2044 | | | | 2045 | SET-RESPONSE | 0x0003 | From FE to CE. Used to carry | 2046 | | | response of a SET | 2047 | | | | 2048 | SET-PROP-RESPONSE | 0x0004 | From FE to CE. Used to carry | 2049 | | | response of a SET-PROP | 2050 | | | | 2051 | DEL | 0x0005 | From CE to FE. Used to delete or | 2052 | | | remove an attribute | 2053 | | | | 2054 | DEL-RESPONSE | 0x0006 | From FE to CE. Used to carry | 2055 | | | response of a DEL | 2056 | | | | 2057 | GET | 0x0007 | From CE to FE. Used to retrieve an | 2058 | | | attribute | 2059 | | | | 2060 | GET-PROP | 0x0008 | From CE to FE. Used to retrieve an | 2061 | | | attribute property | 2062 | | | | 2063 | GET-RESPONSE | 0x0009 | From FE to CE. Used to carry | 2064 | | | response of a GET | 2065 | | | | 2066 | GET-PROP-RESPONSE | 0x000A | From FE to CE. Used to carry | 2067 | | | response of a GET-PROP | 2068 | | | | 2069 | REPORT | 0x000B | From FE to CE. Used to carry an | 2070 | | | asynchronous event | 2071 | | | | 2072 | COMMIT | 0x000C | From CE to FE. Used to issue a | 2073 | | | commit in a 2PC transaction | 2074 | | | | 2075 | COMMIT-RESPONSE | 0x000D | From an FE to CE. Used to confirm a | 2076 | | | commit in a 2PC transaction | 2077 | | | | 2078 | TRCOMP | 0x000E | From CE to FE. Used to indicate | 2079 | | | NE-wide success of 2PC transaction | 2080 +-------------------+--------+--------------------------------------+ 2082 Table 3 2084 Different messages define OPER-TLV are valid and how they are used 2085 (refer to Table 1 and Table 2). 2087 SET, SET-PROP, and GET/GET-PROP requests are issued by the CE and do 2088 not carry RESULT TLVs. On the other hand, SET-RESPONSE, SET-PROP- 2089 RESPONSE and GET-RESPONSE/GET-PROP-RESPONSE carry RESULT TLVs. 2091 A GET-RESPONSE in response to a successful GET will have FULLDATA 2092 TLVs added to the leaf paths to carry the requested data. For GET 2093 operations that fail, instead of the FULLDATA TLV there will be a 2094 RESULT TLV. 2096 For a SET-RESPONSE/SET-PROP-RESPONSE, each FULLDATA or SPARSEDATA TLV 2097 in the original request will be replaced with a RESULT TLV in the 2098 response. If the request set the FailureACK flag, then only those 2099 items which failed will appear in the response. If the request was 2100 for AlwaysACK, then all elements of the request will appear in the 2101 response with RESULT TLVs. 2103 Note that if a SET/SET-PROP request with a structure in a FULLDATA is 2104 issued, and some field in the structure is invalid, the FE will not 2105 attempt to indicate which field was invalid, but rather will indicate 2106 that the operation failed. Note further that if there are multiple 2107 errors in a single leaf PATH-DATA/FULLDATA, the FE can select which 2108 error it chooses to return. So if a FULLDATA for a SET/SET-PROP of a 2109 structure attempts to write one field which is read only, and 2110 attempts to set another field to an invalid value, the FE can return 2111 indication of either error. 2113 A SET/SET-PROP operation on a variable length element with a length 2114 of 0 for the item is not the same as deleting it. If the CE wishes 2115 to delete then the DEL operation should be used whether the path 2116 refers to an array element or an optional structure element. 2118 7.1.7. Result TLV 2120 The RESULT TLV is an instance of TLV defined in Section 6.2. The 2121 definition is as below: 2123 0 1 2 3 2124 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 2125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2126 | Type = RESULT | Length | 2127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2128 | Result Value | Reserved | 2129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2131 Figure 19: Result TLV 2132 Defined Result Values 2134 +-----------------------------+-----------+-------------------------+ 2135 | Result Value | Value | Definition | 2136 +-----------------------------+-----------+-------------------------+ 2137 | E_SUCCESS | 0x00 | Success | 2138 | | | | 2139 | E_INVALID_HEADER | 0x01 | Unspecified error with | 2140 | | | header. | 2141 | | | | 2142 | E_LENGTH_MISMATCH | 0x02 | Header length field | 2143 | | | does not match actual | 2144 | | | packet length. | 2145 | | | | 2146 | E_VERSION_MISMATCH | 0x03 | Unresolvable mismatch | 2147 | | | in versions. | 2148 | | | | 2149 | E_INVALID_DESTINATION_PID | 0x04 | Destination PID is | 2150 | | | invalid for the message | 2151 | | | receiver. | 2152 | | | | 2153 | E_LFB_UNKNOWN | 0x05 | LFB Class ID is not | 2154 | | | known by receiver. | 2155 | | | | 2156 | E_LFB_NOT_FOUND | 0x06 | LFB Class ID is known | 2157 | | | by receiver but not | 2158 | | | currently in use. | 2159 | | | | 2160 | E_LFB_INSTANCE_ID_NOT_FOUND | 0x07 | LFB Class ID is known | 2161 | | | but the specified | 2162 | | | instance of that class | 2163 | | | does not exist. | 2164 | | | | 2165 | E_INVALID_PATH | 0x08 | The specified path is | 2166 | | | impossible. | 2167 | | | | 2168 | E_ELEMENT_DOES_NOT_EXIST | 0x09 | The specified path is | 2169 | | | possible but the | 2170 | | | element does not exist | 2171 | | | (e.g., attempt to | 2172 | | | modify a table row that | 2173 | | | has not been created). | 2174 | | | | 2175 | E_EXISTS | 0x0A | The specified object | 2176 | | | exists but it cannot | 2177 | | | exist for the operation | 2178 | | | to succeed (e.g., | 2179 | | | attempt to add an | 2180 | | | existing LFB instance | 2181 | | | or array subscript). | 2182 | | | | 2183 | E_NOT_FOUND | 0x0B | The specified object | 2184 | | | does not exist but it | 2185 | | | must exist for the | 2186 | | | operation to succeed | 2187 | | | (e.g., attempt to | 2188 | | | delete a non-existing | 2189 | | | LFB instance or array | 2190 | | | subscript). | 2191 | | | | 2192 | E_READ_ONLY | 0x0C | Attempt to modify a | 2193 | | | read-only value. | 2194 | | | | 2195 | E_INVALID_ARRAY_CREATION | 0x0D | Attempt to create an | 2196 | | | array with an unallowed | 2197 | | | subscript. | 2198 | | | | 2199 | E_VALUE_OUT_OF_RANGE | 0x0E | Attempt to set a | 2200 | | | parameter to a value | 2201 | | | outside of its | 2202 | | | allowable range. | 2203 | | | | 2204 | E_CONTENTS_TOO_LONG | 0x0D | Attempt to write | 2205 | | | contents larger than | 2206 | | | the target object space | 2207 | | | (i.e., exceeding a | 2208 | | | buffer). | 2209 | | | | 2210 | E_INVALID_PARAMETERS | 0x10 | Any other error with | 2211 | | | data parameters. | 2212 | | | | 2213 | E_INVALID_MESSAGE_TYPE | 0x11 | Message type is not | 2214 | | | acceptable. | 2215 | | | | 2216 | E_INVALID_FLAGS | 0x12 | Message flags are not | 2217 | | | acceptable for the | 2218 | | | given message type. | 2219 | | | | 2220 | E_INVALID_TLV | 0x13 | A TLV is not acceptable | 2221 | | | for the given message | 2222 | | | type. | 2223 | E_EVENT_ERROR | 0x14 | Unspecified error while | 2224 | | | handling an event. | 2225 | | | | 2226 | E_NOT_SUPPORTED | 0x15 | Attempt to perform a | 2227 | | | valid ForCES operation | 2228 | | | that is unsupported by | 2229 | | | the message receiver. | 2230 | | | | 2231 | E_MEMORY_ERROR | 0x16 | A memory error occurred | 2232 | | | while processing a | 2233 | | | message (no error | 2234 | | | detected in the message | 2235 | | | itself) | 2236 | | | | 2237 | E_INTERNAL_ERROR | 0x17 | An unspecified error | 2238 | | | occurred while | 2239 | | | processing a message | 2240 | | | (no error detected in | 2241 | | | the message itself) | 2242 | | | | 2243 | - | 0x18-0xFE | Reserved | 2244 | | | | 2245 | E_UNSPECIFIED_ERROR | 0xFF | Unspecified error (for | 2246 | | | when the FE can not | 2247 | | | decide what went wrong) | 2248 +-----------------------------+-----------+-------------------------+ 2250 Table 4 2252 7.1.8. DATA TLV 2254 A FULLDATA TLV has "T"= FULLDATA and a 16-bit Length followed by the 2255 data value/contents. Likewise, a SPARSEDATA TLV has "T" = 2256 SPARSEDATA, a 16-bit Length, followed by the data value/contents. In 2257 the case of the SPARSEDATA, each element in the Value part of the TLV 2258 will be further encapsulated in an ILV. 2260 Below are the encoding rules for the FULLDATA and SPARSEDATA TLVs. 2261 Appendix C is very useful in illustrating these rules: 2263 1. Both ILVs and TLVs MUST be 32 bit aligned. Any padding bits used 2264 for the alignment MUST be zero on transmission and MUST be 2265 ignored upon reception. 2267 2. FULLDATA TLVs may be used at a particular path only if every 2268 element at that path level is present. In example 1(c) of 2269 Appendix C this concept is illustrated by the presence of all 2270 elements of the structure S in the FULLDATA TLV encoding. This 2271 requirement holds regardless of whether the fields are fixed or 2272 variable length, mandatory or optional. 2274 * If a FULLDATA TLV is used, the encoder MUST lay out data for 2275 each element in the same order in which the data was defined 2276 in the LFB specification. This ensures the decoder is able to 2277 retrieve the data. To use the example 1 again in Appendix C, 2278 this implies the encoder/decoder is assumed to have knowledge 2279 of how structure S is laid out in the definition. 2281 * In the case of a SPARSEDATA, it does not need to be ordered 2282 since the "I" in the ILV uniquely identifies the element. 2283 Examples 1(a) and 1(b) illustrate the power of SPARSEDATA 2284 encoding. 2286 3. Inside a FULLDATA TLV 2288 * The values for atomic, fixed-length fields are given without 2289 any TLV or ILV encapsulation. 2291 * The values for atomic, variable-length fields are given inside 2292 FULLDATA TLVs. 2294 4. Inside a SPARSEDATA TLV 2296 * The values for atomic fields may be given with ILVs (32-bit 2297 index, 32-bit length) 2299 5. Any of the FULLDATA TLVs can contain an ILV but an ILV cannot 2300 contain a FULLDATA. This is because it is hard to disambiguate 2301 ILV since an I is 32 bits and a T is 16 bits. 2303 6. A FULLDATA can also contain a FULLDATA for variable sized 2304 elements. The decoding disambiguation is assumed from rule #3 2305 above. 2307 7.1.9. SET and GET Relationship 2309 It is expected that a GET-RESPONSE would satisfy the following: 2311 o It would have exactly the same path definitions as those sent in 2312 the GET. The only difference being a GET-RESPONSE will contain 2313 FULLDATA TLVs. 2315 o It should be possible to take the same GET-RESPONSE and convert it 2316 to a SET successfully by merely changing the T in the operational 2317 TLV. 2319 o There are exceptions to this rule: 2321 1. When a KEY selector is used with a path in a GET operation, 2322 that selector is not returned in the GET-RESPONSE; instead the 2323 cooked result is returned. Refer to the examples using KEYS 2324 to see this. 2326 2. When dumping a whole table in a GET, the GET-RESPONSE that 2327 merely edits the T to be SET will end up overwriting the 2328 table. 2330 7.2. Protocol Encoding Visualization 2332 The figure below shows a general layout of the PL PDU. A main header 2333 is followed by one or more LFB selections each of which may contain 2334 one or more operation. 2336 main hdr (Config in this case) 2337 | 2338 | 2339 +--- T = LFBselect 2340 | | 2341 | +-- LFBCLASSID 2342 | | 2343 | | 2344 | +-- LFBInstance 2345 | | 2346 | +-- T = SET 2347 | | | 2348 | | +-- // one or more path targets 2349 | | // with their data here to be added 2350 | | 2351 | +-- T = DEL 2352 | . | 2353 | . +-- // one or more path targets to be deleted 2354 | 2355 | 2356 +--- T = LFBselect 2357 | | 2358 | +-- LFBCLASSID 2359 | | 2360 | | 2361 | +-- LFBInstance 2362 | | 2363 | + -- T= SET 2364 | | . 2365 | | . 2366 | + -- T= DEL 2367 | | . 2368 | | . 2369 | | 2370 | + -- T= SET 2371 | | . 2372 | | . 2373 | 2374 | 2375 +--- T = LFBselect 2376 | 2377 +-- LFBCLASSID 2378 | 2379 +-- LFBInstance 2380 . 2381 . 2382 . 2384 Figure 20: PL PDU logical layout 2386 The figure below shows a more detailed example of the general layout 2387 of the operation within a targeted LFB selection. The idea is to 2388 show the different nesting levels a path could take to get to the 2389 target path. 2391 T = SET 2392 | | 2393 | +- T = Path-data 2394 | | 2395 | + -- flags 2396 | + -- IDCount 2397 | + -- IDs 2398 | | 2399 | +- T = Path-data 2400 | | 2401 | + -- flags 2402 | + -- IDCount 2403 | + -- IDs 2404 | | 2405 | +- T = Path-data 2406 | | 2407 | + -- flags 2408 | + -- IDCount 2409 | + -- IDs 2410 | + -- T = KEYINFO 2411 | | + -- KEY_ID 2412 | | + -- KEY_DATA 2413 | | 2414 | + -- T = FULLDATA 2415 | + -- data 2416 | 2417 | 2418 T = SET 2419 | | 2420 | +- T = Path-data 2421 | | | 2422 | | + -- flags 2423 | | + -- IDCount 2424 | | + -- IDs 2425 | | | 2426 | | + -- T = FULLDATA 2427 | | + -- data 2428 | +- T = Path-data 2429 | | 2430 | + -- flags 2431 | + -- IDCount 2432 | + -- IDs 2433 | | 2434 | + -- T = FULLDATA 2435 | + -- data 2436 T = DEL 2437 | 2438 +- T = Path-data 2439 | 2440 + -- flags 2441 + -- IDCount 2442 + -- IDs 2443 | 2444 +- T = Path-data 2445 | 2446 + -- flags 2447 + -- IDCount 2448 + -- IDs 2449 | 2450 +- T = Path-data 2451 | 2452 + -- flags 2453 + -- IDCount 2454 + -- IDs 2455 + -- T = KEYINFO 2456 | + -- KEY_ID 2457 | + -- KEY_DATA 2458 +- T = Path-data 2459 | 2460 + -- flags 2461 + -- IDCount 2462 + -- IDs 2464 Figure 21: Sample operation layout 2466 Appendix D shows a more concise set of use-cases on how the data 2467 encoding is done. 2469 7.3. Core ForCES LFBs 2471 There are two LFBs that are used to control the operation of the 2472 ForCES protocol and to interact with FEs and CEs: 2474 o FE Protocol LFB 2475 o FE Object LFB 2477 Although these LFBs have the same form and interface as other LFBs, 2478 they are special in many respects. They have fixed well-known LFB 2479 Class and Instance IDs. They are statically defined (no dynamic 2480 instantiation allowed) and their status cannot be changed by the 2481 protocol: any operation to change the state of such LFBs (for 2482 instance, in order to disable the LFB) must result in an error. 2483 Moreover, these LFBs must exist before the first ForCES message can 2484 be sent or received. All attributes in these LFBs must have pre- 2485 defined default values. Finally, these LFBs do not have input or 2486 output ports and do not integrate into the intra-FE LFB topology. 2488 7.3.1. FE Protocol LFB 2490 The FE Protocol LFB is a logical entity in each FE that is used to 2491 control the ForCES protocol. The FE Protocol LFB Class ID is 2492 assigned the value 0x1. The FE Protocol LFB Instance ID is assigned 2493 the value 0x1. There MUST be one and only one instance of the FE 2494 Protocol LFB in an FE. The values of the attributes in the FE 2495 Protocol LFB have pre-defined default values that are specified here. 2496 Unless explicit changes are made to these values using Config 2497 messages from the CE, these default values MUST be used for correct 2498 operation of the protocol. 2500 The formal definition of the FE Protocol Object LFB can be found in 2501 Appendix B. 2503 7.3.1.1. FE Protocol capabilities 2505 FE Protocol capabilities are read-only. 2507 7.3.1.1.1. SupportableVersions 2509 ForCES protocol version(s) supported by the FE 2511 7.3.1.1.2. FE Protocol Attributes 2513 FE Protocol attributes (can be read and set). 2515 7.3.1.1.2.1. CurrentRunningVersion 2517 Current running version of the ForCES protocol 2519 7.3.1.1.2.2. FEID 2521 FE unicast ID 2523 7.3.1.1.2.3. MulticastFEIDs 2525 FE multicast ID(s) list - this is a list of multicast IDs that the FE 2526 belongs to. These IDs are configured by the CE. 2528 7.3.1.1.2.4. CEHBPolicy 2530 CE heartbeat policy - This policy, along with the parameter 'CE 2531 Heartbeat Dead Interval (CE HDI)' as described below defines the 2532 operating parameters for the FE to check the CE liveness. The policy 2533 values with meanings are listed as below: 2535 o 0 (default) - This policy specifies that the CE will send a 2536 Heartbeat Message to the FE(s) whenever the CE reaches a time 2537 interval within which no other PL messages were sent from the CE 2538 to the FE(s); refer to Section 4.3.3 and Section 7.10 for details. 2539 The CE HDI attribute as described below is tied to this policy. 2541 o 1 - The CE will not generate any HB messages. This actually means 2542 CE does not want the FE to check the CE liveness. 2544 o Others - reserved. 2546 7.3.1.1.2.5. CEHDI 2548 CE Heartbeat Dead Interval (CE HDI) - The time interval the FE uses 2549 to check the CE liveness. If FE has not received any messages from 2550 CE within this time interval, FE deduces lost connectivity which 2551 implies that the CE is dead or the association to the CE is lost. 2552 Default value 30 s. 2554 7.3.1.1.2.6. FEHBPolicy 2556 FE heartbeat policy - This policy, along with the parameter 'FE 2557 Heartbeat Interval (FE HI)', defines the operating parameters for how 2558 the FE should behave so that the CE can deduce its liveness. The 2559 policy values and the meanings are: 2561 o 0 (default) - The FE should not generate any Heartbeat messages. 2562 In this scenario, the CE is responsible for checking FE liveness 2563 by setting the PL header ACK flag of the message it sends to 2564 AlwaysACK. The FE responds to CE whenever CE sends such Heartbeat 2565 Request Message. Refer to Section 7.10 and Section 4.3.3 for 2566 details. 2568 o 1 - This policy specifies that FE must actively send a Heartbeat 2569 Message if it reaches the time interval assigned by the FE HI as 2570 long as no other messages were sent from FE to CE during that 2571 interval as described in Section 4.3.3. 2573 o Others - Reserved. 2575 7.3.1.1.2.7. FEHI 2577 FE Heartbeat Interval (FE HI) - The time interval the FE should use 2578 to send HB as long as no other messages were sent from FE to CE 2579 during that interval as described in Section 4.3.3. The default 2580 value for an FE HI is 500ms. 2582 7.3.1.1.2.8. CEID 2584 Primary CEID - The CEID that the FE is associated with. 2586 7.3.1.1.2.9. LastCEID 2588 Last Primary CEID - The CEID of the last CE that that the FE 2589 associated with. This CE ID is reported to the new Primary CEID. 2591 7.3.1.1.2.10. BackupCEs 2593 The list of backup CEs an FE can use as backups. Refer to Section 8 2594 for details. 2596 7.3.1.1.2.11. CEFailoverPolicy 2598 CE failover policy - This specifies the behavior of the FE when the 2599 association with the CE is lost. There is a very tight relation 2600 between CE failover policy and Section 7.3.1.1.2.8, 2601 Section 7.3.1.1.2.10, Section 7.3.1.1.2.12, and Section 8. When an 2602 association is lost, depending on configuration, one of the policies 2603 listed below is activated. 2605 o 0 (default) - FE should stop functioning immediately and 2606 transition to FE DOWN. 2608 o 1 - The FE should continue running and do what it can even without 2609 an associated CE. This basically requires that the FE support CE 2610 Graceful restart (and defines such support in its capabilities). 2611 If the CEFTI expires before the FE re-associates with either the 2612 primary (Section 7.3.1.1.2.8) or one of possibly several backup 2613 CEs (Section 7.3.1.1.2.10), the FE will go operationally down. 2615 o Others - Reserved 2617 7.3.1.1.2.12. CEFTI 2619 CE Failover Timeout Interval (CEFTI) - The time interval associated 2620 with the CE failover policy case '0' and '2'. The default value is 2621 set to 300 seconds. Note that it is advisable to set the CEFTI value 2622 much higher than the CE Heartbeat Dead Interval (CE HDI) since the 2623 effect of expiring this parameter is devastating to the operation of 2624 the FE. 2626 7.3.1.1.2.13. FERestartPolicy 2628 FE restart policy - This specifies the behavior of the FE during an 2629 FE restart. The restart may be from an FE failure or other reasons 2630 that have made FE down and then need to restart. The values are 2631 defined as below: 2633 o 0(default)- Restart the FE from scratch. In this case, the FE 2634 should start from the pre-association phase. 2636 o others - Reserved for future use. 2638 7.3.2. FE Object LFB 2640 The FE Object LFB is a logical entity in each FE and contains 2641 attributes relative to the FE itself, and not to the operation of the 2642 ForCES protocol. 2644 The formal definition of the FE Object LFB can be found in 2645 [FE-MODEL]. The model captures the high level properties of the FE 2646 that the CE needs to know to begin working with the FE. The class ID 2647 for this LFB Class is also assigned in [FE-MODEL]. The singular 2648 instance of this class will always exist, and will always have 2649 instance ID 0x1 within its class. It is common, although not 2650 mandatory, for a CE to fetch much of the attribute and capability 2651 information from this LFB instance when the CE begins controlling the 2652 operation of the FE. 2654 7.4. Semantics of Message Direction 2656 Recall: The PL provides a master(CE)-Slave(FE) relationship. The 2657 LFBs reside at the FE and are controlled by CE. 2659 When messages go from the CE, the LFB Selector (Class and instance) 2660 refers to the destination LFB selection which resides in the FE. 2662 When messages go from the FE to the CE, the LFB Selector (Class and 2663 instance) refers to the source LFB selection which resides in the FE. 2665 7.5. Association Messages 2667 The ForCES Association messages are used to establish and teardown 2668 associations between FEs and CEs. 2670 7.5.1. Association Setup Message 2672 This message is sent by the FE to the CE to setup a ForCES 2673 association between them. 2675 Message transfer direction: 2676 FE to CE 2678 Message header: 2679 The Message Type in the header is set MessageType= 2680 'AssociationSetup'. The ACK flag in the header MUST be ignored, 2681 and the association setup message always expects to get a response 2682 from the message receiver (CE), whether the setup is successful or 2683 not. The correlator field in the header is set, so that FE can 2684 correlate the response coming back from the CE correctly. The FE 2685 may set the source ID to 0 in the header to request that the CE 2686 should assign an FE ID for the FE in the setup response message. 2688 Message body: 2689 The association setup message body optionally consists of zero, 2690 one or two LFBselect TLVs, as described in Section 7.1.5. The 2691 Association Setup message only operates on the FE Object and FE 2692 Protocol LFBs, therefore, the LFB class ID in the LFBselect TLV 2693 only points to these two kinds of LFBs. 2695 The OPER-TLV in the LFBselect TLV is defined as a 'REPORT' 2696 operation. More than one attribute may be announced in this 2697 message using REPORT operation to let the FE declare its 2698 configuration parameters in an unsolicited manner. These may 2699 contain attributes suggesting values such as the FE HB Interval, 2700 or the FEID. The OPER-TLV used is defined below. 2702 OPER-TLV for Association Setup: 2704 0 1 2 3 2705 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 2706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2707 | Type = REPORT | Length | 2708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2709 | PATH-DATA-TLV for REPORT | 2710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2712 Figure 22: OPER-TLV 2714 Type: 2715 Only one operation type is defined for the association setup 2716 message: 2718 Type = "REPORT" - this type of operation is for FE to 2719 report something to CE. 2721 PATH-DATA-TLV for REPORT: 2722 This is generically a PATH-DATA-TLV format that has been defined 2723 in section (Section 7) in the PATH-DATA BNF definition. The PATH- 2724 DATA-TLV for REPORT operation MAY contain FULLDATA-TLV(s) but 2725 SHALL NOT contain any RESULT TLV in the data format. The RESULT 2726 TLV is defined in Section 7.1.7 and the FULLDATA-TLV is defined in 2727 Section 7.1.8. 2729 To better illustrate the above PDU format, a tree structure for the 2730 format is shown below: 2732 main hdr (type = Association Setup) 2733 | 2734 | 2735 +--- T = LFBselect 2736 | | 2737 | +-- LFBCLASSID = FE object 2738 | | 2739 | | 2740 | +-- LFBInstance = 0x1 2741 | 2742 +--- T = LFBselect 2743 | 2744 +-- LFBCLASSID = FE Protocol object 2745 | 2746 | 2747 +-- LFBInstance = 0x1 2748 | 2749 +---OPER-TLV = REPORT 2750 | 2751 +-- Path-data to one or more attributes 2753 Figure 23: PDU Format For Association Setup Message 2755 7.5.2. Association Setup Response Message 2757 This message is sent by the CE to the FE in response to the Setup 2758 message. It indicates to the FE whether the setup is successful or 2759 not, i.e., whether an association is established. 2761 Message transfer direction: 2762 CE to FE 2764 Message Header: 2765 The Message Type in the header is set MessageType= 2766 'AssociationSetupResponse'. The ACK flag in the header MUST be 2767 ignored, and the setup response message never expects to get any 2768 more responses from the message receiver (FE). The destination 2769 ID in the header will be set to the source ID in the 2770 corresponding association setup message, unless that source ID 2771 was 0. If the corresponding source ID was 0, then the CE will 2772 assign an FE ID value and use that value for the destination ID. 2774 0 1 2 3 2775 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 2776 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2777 | Type = ASRresult | Length | 2778 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2779 | Association Setup Result | 2780 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2782 Figure 24: ASResult OPER-TLV 2784 Type (16 bits): 2785 The type of the TLV is "ASResult". 2787 Length (16 bits): 2788 Length of the TLV including the T and L fields, in octets. 2790 Association Setup Result (32 bits): 2791 This indicates whether the setup msg was successful or whether 2792 the FE request was rejected by the CE. the defined values are: 2794 0 = success 2796 1 = FE ID invalid 2798 2 = permission denied 2800 To better illustrate the above PDU format, a tree structure for the 2801 format is shown below: 2803 main hdr (type = Association Setup Response) 2804 | 2805 | 2806 +--- T = ASResult 2808 Figure 25: PDU Format for Association Setup Repsonse Message 2810 7.5.3. Association Teardown Message 2812 This message can be sent by the FE or CE to any ForCES element to end 2813 its ForCES association with that element. 2815 Message transfer direction: 2816 CE to FE, or FE to CE (or CE to CE) 2818 Message Header: 2819 The Message Type in the header is set MessageType= 2820 "AssociationTeardown". The ACK flag MUST be ignored. The 2821 correlator field in the header MUST be set to zero and MUST be 2822 ignored by the receiver. 2824 0 1 2 3 2825 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 2826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2827 | Type = ASTreason | Length | 2828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2829 | Teardown Reason | 2830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2832 Figure 26: ASTreason TLV 2834 Type (16 bits): 2835 The type of the TLV is "ASTreason". 2837 Length (16 bits): 2838 Length of the TLV including the T and L fields, in octets. 2840 Teardown Reason (32 bits): 2841 This indicates the reason why the association is being 2842 terminated. Several reason codes are defined as follows. 2844 0 - normal teardown by administrator 2846 1 - error - loss of heartbeats 2848 2 - error - out of bandwidth 2850 3 - error - out of memory 2852 4 - error - application crash 2854 255 - error - other or unspecified 2856 To better illustrate the above PDU format, a tree structure for the 2857 format is shown below: 2859 main hdr (type = Association Teardown) 2860 | 2861 | 2862 +--- T = ASTreason 2864 Figure 27: PDU Format for Association Teardown Message 2866 7.6. Configuration Messages 2868 The ForCES Configuration messages are used by CE to configure the FEs 2869 in a ForCES NE and report the results back to the CE. 2871 7.6.1. Config Message 2873 This message is sent by the CE to the FE to configure LFB attributes 2874 in the FE. This message is also used by the CE to subscribe/ 2875 unsubscribe to LFB events. 2877 As usual, a config message is composed of a common header followed by 2878 a message body that consists of one or more TLV data format. 2879 Detailed description of the message is as below. 2881 Message transfer direction: 2882 CE to FE 2884 Message Header: 2885 The Message Type in the header is set MessageType= 'Config'. The 2886 ACK flag in the header can be set to any value defined in 2887 Section 6.1, to indicate whether or not a response from FE is 2888 expected by the message. 2890 OPER-TLV for Config: 2892 0 1 2 3 2893 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 2894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2895 | Type | Length | 2896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2897 | PATH-DATA-TLV | 2898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2900 Figure 28: OPER-TLV for Config 2902 Type: 2903 The operation type for config message. two types of operations 2904 for the config message are defined: 2906 Type = "SET" - this operation is to set LFB attributes 2908 Type = "SET-PROP" - this operation is to set LFB attribute 2909 properties 2910 Type = "DEL" - this operation to delete some LFB 2911 attributes 2913 Type = "COMMIT" - this operation is sent to the FE to 2914 commit in a 2pc transaction. A COMMIT TLV is an empty TLV 2915 i.e it has no "V"alue. In other words, There is a Length 2916 of 4 (which is for the header only). 2918 Type = "TRCOMP" - this operation is sent to the FE to mark 2919 the success from an NE perspective of a 2pc transaction. 2920 A TRCOMP TLV is an empty TLV i.e it has no "V"alue. In 2921 other words, There is a Length of 4 (which is for the 2922 header only). 2924 PATH-DATA-TLV: 2925 This is generically a PATH-DATA-TLV format that has been defined 2926 in section (Section 7) in the PATH-DATA BNF definition. The 2927 restriction on the use of PATH-DATA-TLV for SET/SET-PROP 2928 operation is that it MUST contain either a FULLDATA or SPARSEDATA 2929 TLV(s), but MUST NOT contain any RESULT TLV. The restriction on 2930 the use of PATH-DATA-TLV for DEL operation is it MAY contain 2931 FULLDATA or SPARSEDATA TLV(s), but MUST NOT contain any RESULT 2932 TLV. The RESULT TLV is defined in Section 7.1.7 and FULLDATA and 2933 SPARSEDATA TLVs is defined in Section 7.1.8. 2935 *Note: For Event subscription, the events will be defined by the 2936 individual LFBs. 2938 To better illustrate the above PDU format, a tree structure for the 2939 format is shown below: 2941 main hdr (type = Config) 2942 | 2943 | 2944 +--- T = LFBselect 2945 . | 2946 . +-- LFBCLASSID = target LFB class 2947 . | 2948 | 2949 +-- LFBInstance = target LFB instance 2950 | 2951 | 2952 +-- T = operation { SET } 2953 | | 2954 | +-- // one or more path targets 2955 | // associated with FULL or SPARSEDATA TLV(s) 2956 | 2957 +-- T = operation { DEL } 2958 | | 2959 | +-- // one or more path targets 2960 | 2961 +-- T = operation { COMMIT } //A COMMIT TLV is an empty TLV 2962 . 2963 . 2965 Figure 29: PDU Format for Configuration Message 2967 7.6.2. Config Response Message 2969 This message is sent by the FE to the CE in response to the Config 2970 message. It indicates whether the Config was successful or not on 2971 the FE and also gives a detailed response regarding the configuration 2972 result of each attribute. 2974 Message transfer direction: 2975 FE to CE 2977 Message Header: 2978 The Message Type in the header is set MessageType= 'Config 2979 Response'. The ACK flag in the header is always ignored, and the 2980 Config Response message never expects to get any further response 2981 from the message receiver (CE). 2983 OPER-TLV for Config Response: 2985 0 1 2 3 2986 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 2987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2988 | Type | Length | 2989 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2990 | PATH-DATA-TLV | 2991 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2993 Figure 30: OPER-TLV for Config Response 2995 Type: 2996 The operation type for Config Response message. Two types of 2997 operations for the Config Response message are defined: 2999 Type = "SET-RESPONSE" - this operation is for the response 3000 of SET operation of LFB attributes 3002 Type = "SET-PROP-RESPONSE" - this operation is for the 3003 response of SET-PROP operation of LFB attribute properties 3005 Type = "DEL-RESPONSE" - this operation is for the response 3006 of the DELETE operation of LFB attributes 3008 Type = "COMMIT-RESPONSE" - this operation is sent to the 3009 CE to confirm a commit success in a 2pc transaction. A 3010 COMMIT-RESPONSE TLV MUST contain a RESULT TLV indicating 3011 success or failure. 3013 PATH-DATA-TLV: 3014 This is generically a PATH-DATA-TLV format that has been defined 3015 in section (Section 7) in the PATH-DATA BNF definition. The 3016 restriction on the use of PATH-DATA-TLV for SET-RESPONSE 3017 operation is that it MUST contain RESULT TLV(s). The restriction 3018 on the use of PATH-DATA-TLV for DEL-RESPONSE operation is it also 3019 MUST contain RESULT TLV(s). The RESULT TLV is defined in 3020 Section 7.1.7. 3022 To better illustrate the above PDU format, a tree structure for the 3023 format is shown below: 3025 main hdr (type = ConfigResponse) 3026 | 3027 | 3028 +--- T = LFBselect 3029 . | 3030 . +-- LFBCLASSID = target LFB class 3031 . | 3032 | 3033 +-- LFBInstance = target LFB instance 3034 | 3035 | 3036 +-- T = operation { SET-RESPONSE } 3037 | | 3038 | +-- // one or more path targets 3039 | // associated with FULL or SPARSEDATA TLV(s) 3040 | 3041 +-- T = operation { DEL-RESPONSE } 3042 | | 3043 | +-- // one or more path targets 3044 | 3045 +-- T = operation { COMMIT-RESPONSE } 3046 | | 3047 | +-- RESULT 3049 Figure 31: PDU Format fpr Configuration Response message 3051 7.7. Query Messages 3053 The ForCES query messages are used by the CE to query LFBs in the FE 3054 for informations like LFB attributes, capabilities, statistics, etc. 3055 Query Messages include the Query Message and the Query Response 3056 Message. 3058 7.7.1. Query Message 3060 A Query message is composed of a common header and a message body 3061 that consists of one or more TLV data format. Detailed description 3062 of the message is as below. 3064 Message transfer direction: 3065 from CE to FE 3067 Message Header: 3068 The Message Type in the header is set to MessageType= 'Query'. 3069 The ACK flag in the header is always ignored, and a full response 3070 for a query message is always expected. The Correlator field in 3071 the header is set, so that the CE can locate the response back 3072 from FE correctly. 3074 OPER-TLV for Query: 3076 0 1 2 3 3077 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 3078 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3079 | Type = GET/GET-PROP | Length | 3080 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3081 | PATH-DATA-TLV for GET/GET-PROP | 3082 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3084 Figure 32: TLV for Query 3086 Type: 3087 The operation type for query. Two operation types are defined: 3089 Type = "GET" - this operation is to request to get LFB 3090 attributes. 3092 Type = "GET-PROP" - this operation is to request to get 3093 LFB attributes. 3095 PATH-DATA-TLV for GET/GET-PROP: 3096 This is generically a PATH-DATA-TLV format that has been defined 3097 in section (Section 7) in the PATH-DATA BNF definition. The 3098 restriction on the use of PATH-DATA-TLV for GET/GET-PROP 3099 operation is it MUST NOT contain any SPARSEDATA or FULLDATA TLV 3100 and RESULT TLV in the data format. 3102 To better illustrate the above PDU format, a tree structure for the 3103 format is shown below: 3105 main hdr (type = Query) 3106 | 3107 | 3108 +--- T = LFBselect 3109 . | 3110 . +-- LFBCLASSID = target LFB class 3111 . | 3112 | 3113 +-- LFBInstance = target LFB instance 3114 | 3115 | 3116 +-- T = operation { GET } 3117 | | 3118 | +-- // one or more path targets 3119 | 3120 +-- T = operation { GET } 3121 . | 3122 . +-- // one or more path targets 3123 . 3125 Figure 33: PDU Format for Query Message 3127 7.7.2. Query Response Message 3129 When receiving a Query message, the receiver should process the 3130 message and come up with a query result. The receiver sends the 3131 query result back to the message sender by use of the Query Response 3132 Message. The query result can be the information being queried if 3133 the query operation is successful, or can also be error codes if the 3134 query operation fails, indicating the reasons for the failure. 3136 A Query Response message is also composed of a common header and a 3137 message body consisting of one or more TLVs describing the query 3138 result. Detailed description of the message is as below. 3140 Message transfer direction: 3141 from FE to CE 3143 Message Header: 3144 The Message Type in the header is set to MessageType= 3145 'QueryResponse'. The ACK flag in the header is ignored. As a 3146 response itself, the message does not expect a further response. 3148 OPER-TLV for Query Response: 3150 0 1 2 3 3151 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 3152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3153 |Type = GET-RESPONSE/GET-PROP-RESPONSE| Length | 3154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3155 | PATH-DATA-TLV for GET-RESPONSE/GET-PROP-RESPONSE | 3156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3158 Figure 34: TLV for Query Response 3160 Type: 3161 The operation type for query response. One operation type is 3162 defined: 3164 Type = "GET-RESPONSE" - this operation is to response to 3165 get operation of LFB attributes. 3167 Type = "GET-PROP-RESPONSE" - this operation is to response 3168 to GET-PROP operation of LFB attributes. 3170 PATH-DATA-TLV for GET-RESPONSE/GET-PROP-RESPONSE: 3171 This is generically a PATH-DATA-TLV format that has been defined 3172 in section (Section 7) in the PATH-DATA BNF definition. The 3173 PATH-DATA-TLV for GET-RESPONSE operation MAY contain SPARSEDATA 3174 TLV, FULLDATA TLV and/or RESULT TLV(s) in the data encoding. The 3175 RESULT TLV is defined in Section 7.1.7 and the SPARSEDATA and 3176 FULLDATA TLVs are defined in Section 7.1.8. 3178 To better illustrate the above PDU format, a tree structure for the 3179 format is shown below: 3181 main hdr (type = QueryResponse) 3182 | 3183 | 3184 +--- T = LFBselect 3185 . | 3186 . +-- LFBCLASSID = target LFB class 3187 . | 3188 | 3189 +-- LFBInstance = target LFB instance 3190 | 3191 | 3192 +-- T = operation { GET-RESPONSE } 3193 | | 3194 | +-- // one or more path targets 3195 | 3196 +-- T = operation { GET-PROP-RESPONSE } 3197 . | 3198 . +-- // one or more path targets 3199 . 3201 Figure 35: PDU Format for Query Response Message 3203 7.8. Event Notification Message 3205 Event Notification Message is used by FE to asynchronously notify CE 3206 of events that happen in the FE. 3208 All events that can be generated in an FE are subscribable by the CE. 3209 The CE can subscribe to an event via a Config message with SET-PROP 3210 operation, where the included path specifies the event, as defined by 3211 the LFB Library and described by the FE Model. 3213 As usual, an Event Notification Message is composed of a common 3214 header and a message body that consists of one or more TLV data 3215 format. Detailed description of the message is as below. 3217 Message Transfer Direction: 3218 FE to CE 3220 Message Header: 3221 The Message Type in the message header is set to 3222 MessageType = 'EventNotification'. The ACK flag in the header 3223 MUST be ignored by the CE, and the event notification message does 3224 not expect any response from the receiver. 3226 OPER-TLV for Event Notification: 3228 0 1 2 3 3229 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 3230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3231 | Type = REPORT | Length | 3232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3233 | PATH-DATA-TLV for REPORT | 3234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3236 Figure 36: TLV for Event Notification 3238 Type: 3239 Only one operation type is defined for the event notification 3240 message: 3242 Type = "REPORT" - this type of operation is for FE to 3243 report something to CE. 3245 PATH-DATA-TLV for REPORT: 3246 This is generically a PATH-DATA-TLV format that has been defined 3247 in section (Section 7) in the PATH-DATA BNF definition. The PATH- 3248 DATA-TLV for REPORT operation MAY contain FULLDATA or SPARSEDATA 3249 TLV(s) but MUST NOT contain any RESULT TLV in the data format. 3251 To better illustrate the above PDU format, a tree structure for the 3252 format is shown below: 3254 main hdr (type = Event Notification) 3255 | 3256 | 3257 +--- T = LFBselect 3258 | 3259 +-- LFBCLASSID = target LFB class 3260 | 3261 | 3262 +-- LFBInstance = target LFB instance 3263 | 3264 | 3265 +-- T = operation { REPORT } 3266 | | 3267 | +-- // one or more path targets 3268 | // associated with FULL/SPARSE DATA TLV(s) 3269 +-- T = operation { REPORT } 3270 . | 3271 . +-- // one or more path targets 3272 . // associated with FULL/SPARSE DATA TLV(s) 3274 Figure 37: PDU Format for Event Notification Message 3276 7.9. Packet Redirect Message 3278 A packet Redirect message is used to transfer data packets between CE 3279 and FE. Usually these data packets are control packets but they may 3280 be just data-path packets which need further (exception or high- 3281 touch) processing. It is also feasible that this message carries no 3282 data packets and rather just metadata. 3284 The Packet Redirect message data format is formated as follows: 3286 Message Direction: 3287 CE to FE or FE to CE 3289 Message Header: 3290 The Message Type in the header is set to MessageType= 3291 'PacketRedirect'. 3293 Message Body: 3294 This consists of one or more TLVs that contain or describe the 3295 packet being redirected. The TLV is specifically a Redirect TLV 3296 (with the TLV Type="Redirect"). Detailed data format of a 3297 Redirect TLV for packet redirect message is as below: 3299 0 1 2 3 3300 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 3301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3302 | Type = Redirect | Length | 3303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3304 | Meta Data TLV | 3305 . . 3306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3307 | Redirect Data TLV | 3308 . . 3309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3311 Figure 38: Redirect_Data TLV 3313 Meta Data TLV: 3314 This is a TLV that specifies meta-data associated with followed 3315 redirected data. The TLV is as follows: 3317 0 1 2 3 3318 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 3319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3320 | Type = METADATA | Length | 3321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3322 | Meta Data ILV | 3323 . . 3324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3325 ~ ... ~ 3326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3327 | Meta Data ILV | 3328 . . 3329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3331 Figure 39: METADARA TLV 3333 Meta Data ILV: 3334 This is an Identifier-Length-Value format that is used to describe 3335 one meta data. The ILV has the format as: 3337 0 1 2 3 3338 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 3339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3340 | Meta Data ID | 3341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3342 | Length | 3343 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3344 | Meta Data Value | 3345 . . 3346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3348 Figure 40: Meta Data ILV 3350 Where, Meta Data ID is an identifier for the meta data, which is 3351 statically assigned by the LFB definition. 3353 Redirect Data TLV 3354 This is a TLV describing one packet of data to be directed via the 3355 redirect operation. The TLV format is as follows: 3357 0 1 2 3 3358 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 3359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3360 | Type = REDIRECTDATA | Length | 3361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3362 | Redirected Data | 3363 . . 3364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 3366 Figure 41: Redirect Data TLV 3368 Redirected Data: 3369 This field contains the packet that is to be redirected in network 3370 byte order. The packet should be 32-bits aligned as is the data 3371 for all TLVs. The metadata infers what kind of packet is carried 3372 in value field and therefore allows for easy decoding of data 3373 encapsulated 3375 To better illustrate the above PDU format, a tree structure for the 3376 format is shown below: 3378 main hdr (type = PacketRedirect) 3379 | 3380 | 3381 +--- T = Redirect 3382 . | 3383 . +-- T = METADATA 3384 | | 3385 | +-- Meta Data ILV 3386 | | 3387 | +-- Meta Data ILV 3388 | . 3389 | . 3390 | 3391 +-- T = REDIRECTDATA 3392 | 3393 +-- // Redirected Data 3395 Figure 42: PDU Format for Packet Redirect Message 3397 7.10. Heartbeat Message 3399 The Heartbeat (HB) Message is used for one ForCES element (FE or CE) 3400 to asynchronously notify one or more other ForCES elements in the 3401 same ForCES NE on its liveness. Section 4.3.3 describes the traffic- 3402 sensitive approach used. 3404 A Heartbeat Message is sent by a ForCES element periodically. The 3405 parameterization and policy definition for heartbeats for an FE is 3406 managed as attributes of the FE Protocol Object LFB, and can be set 3407 by CE via a Config message. The Heartbeat message is a little 3408 different from other protocol messages in that it is only composed of 3409 a common header, with the message body left empty. A detailed 3410 description of the message is as below. 3412 Message Transfer Direction: 3413 FE to CE or CE to FE 3415 Message Header: 3416 The Message Type in the message header is set to MessageType = 3417 'Heartbeat'. Section 4.3.3 describes the HB mechanisms used. 3418 The ACK flag in the header MUST be set to either 'NoACK' or 3419 'AlwaysACK' when the HB is sent. 3421 * When set to 'NoACK', the HB is not soliciting for a response. 3423 * When set to 'AlwaysACK', the HB Message sender is always 3424 expecting a response from its receiver. According the HB 3425 policies defined in Section 7.3.1, only the CE can send such 3426 an HB message to query FE liveness. For simplicity and 3427 because of the minimal nature of the HB message, the response 3428 to a HB message is another HB message, i.e., no specific HB 3429 response message is defined. Whenever an FE receives a HB 3430 message marked with 'AlwaysACK' from the CE, the FE MUST send 3431 a HB message back immediately. The HB message sent by the FE 3432 in response to the 'AlwasyACK' MUST modify the source and 3433 destination IDs so that the ID of the FE is the source ID and 3434 the CE ID of the sender is the destination ID, and MUST 3435 change the ACK information to 'NoACK'. A CE MUST NOT respond 3436 to an HB message with 'AlwasyACK' set. 3438 * When set to anything else other than 'NoACK' or 'AlwaysACK', 3439 the HB Message is treated as if it was a 'NoACK'. 3441 The correlator field in the HB message header SHOULD be set 3442 accordingly when a response is expected so that a receiver can 3443 correlate the response correctly. The correlator field MAY be 3444 ignored if no response is expected. 3446 Message Body: 3447 The message body is empty for the Heartbeat Message. 3449 8. High Availability Support 3451 The ForCES protocol provides mechanisms for CE redundancy and 3452 failover, in order to support High Availability as defined in 3453 [RFC3654]. FE redundancy and FE to FE interaction is currently out 3454 of scope of this document. There can be multiple redundant CEs and 3455 FEs in a ForCES NE. However, at any one time only one primary CE can 3456 control the FEs though there can be multiple secondary CEs. The FE 3457 and the CE PL are aware of the primary and secondary CEs. This 3458 information (primary, secondary CEs) is configured in the FE and in 3459 the CE PLs during pre-association by the FEM and the CEM 3460 respectively. Only the primary CE sends control messages to the FEs. 3462 8.1. Relation with the FE Protocol 3464 High Availability parameterization in an FE is driven by configuring 3465 the FE Protocol Object LFB (refer to Appendix B and Section 7.3.1). 3466 The FE Heartbeat Interval, CE Heartbeat Dead Interval, and CE 3467 Heartbeat policy help in detecting connectivity problems between an 3468 FE and CE. The CE Failover policy defines the reaction on a detected 3469 failure. 3471 Figure 43 extends the state machine illustrated in Figure 4 to allow 3472 for new states that facilitate connection recovery. 3474 +-----------------+ 3475 Lost association && | Pre-Association | 3476 CE failover policy = 0 | (Association | 3477 +------------>-->--| in +<----+ 3478 | | progress) | | 3479 | +--------+--------+ | 3480 | | | 3481 | Y | 3482 | | | 3483 | Associated ^ 3484 | | | 3485 | Y | 3486 | | | 3487 | +-------+-------+ | 3488 | CE issues | DOWN FE | | 3489 | FEO Admin | (ForCES | ^ 3490 | UP | Active) | | 3491 | +-------- | | | 3492 | | | | | 3493 | | +---------------+ ^ 3494 | Y ^ | 3495 | | | |CEFTI expired 3496 | Y |CE issues Admin | && 3497 | | | DOWN |!connected 3498 | | | ^ 3499 | Y | | 3500 +-+-----------+ | +------+------+ 3501 | UP |------------+ |Disconnected | 3502 |(associated) | | | 3503 | |Lost association | | 3504 | | && | | 3505 | |--------->------>----->|(Continue | 3506 | |CE failover policy |Forwarding) | 3507 | | = 1 | | 3508 +-------------+ +-------------+ 3509 ^ | 3510 | Resynchronize !CEFTI expired | 3511 | complete && | 3512 | reconnected | 3513 | +---------------+ | 3514 | | Resynch state | | 3515 | | (via | | 3516 +-----------| graceful |<--------+ 3517 | restart) | 3518 +---------------+ 3520 Figure 43: FE State Machine considering HA 3522 Section 4.2 describes transitions between the UP, DOWN and Pre- 3523 association states. In this section we deal with disconnected 3524 states. 3526 During a communication failure between the FE and CE (which is caused 3527 due to CE or link reasons, i.e. not FE related), either the TML on 3528 the FE will trigger the FE PL regarding this failure or it will be 3529 detected using the HB messages between FEs and CEs. The 3530 communication failure, regardless of how it is detected, MUST be 3531 considered as a loss of association between the CE and corresponding 3532 FE. 3534 If the FE's FEPO CE Failover Policy is configured to mode 0 (the 3535 default), it will immediately transition to the pre-association 3536 phase. This means that if it ever reconnects again, it will re- 3537 establish state from scratch. 3539 If the FE's FEPO CE Failover Policy is configured to mode 1, it 3540 implies that the FE is capable of HA as well as graceful restart 3541 recovery. In such a case, the FE transitions to the disconnected 3542 state and the CEFTI timer is started. The FE continues to forward 3543 packets during this state. It also recycles through its configured 3544 secondary CEs in a round-robin fashion. It first adds its primary CE 3545 to the tail of backup CEs and sets its primary CE to be the first 3546 secondary. It then attempts to connect to associate with the new 3547 primary CE. If it fails to re-associate with any CE and the CEFTI 3548 expires, the FE transitions to the Pre-association state. 3550 If the FE, while in the Disconnected state, manages to reconnect to a 3551 new primary CE before CEFTI expires it transitions to the Resynch 3552 state. In the Resynch state, the FE tries to recover any state that 3553 may have been lost during the Disonnected state. Graceful restart is 3554 one such mechanism. How the FE achieves these goals is out of scope 3555 for this document. 3557 Figure 44 below illustrates the Forces message sequences that the FE 3558 uses to recover the connection. 3560 FE CE Primary CE Secondary 3561 | | | 3562 | Asso Estb,Caps exchg | | 3563 1 |<--------------------->| | 3564 | | | 3565 | All msgs | | 3566 2 |<--------------------->| | 3567 | | | 3568 | | | 3569 | FAILURE | 3570 | | 3571 | Asso Estb,Caps exchange | 3572 3 |<------------------------------------------>| 3573 | | 3574 | Event Report (pri CE down) | 3575 4 |------------------------------------------->| 3576 | | 3577 | All Msgs | 3578 5 |<------------------------------------------>| 3580 Figure 44: CE Failover for Report Primary Mode 3582 A CE-to-CE synchronization protocol would be needed to support fast 3583 failover as well as to address some of the corner cases, however this 3584 will not be defined by the ForCES protocol as it is out of scope for 3585 this specification. 3587 An explicit message (a Config message setting Primary CE attribute in 3588 ForCES Protocol object) from the primary CE, can also be used to 3589 change the Primary CE for an FE during normal protocol operation. 3591 Also note that the FEs in a ForCES NE could also use a multicast CE 3592 ID, i.e., they could be associated with a group of CEs (this assumes 3593 the use of a CE-CE synchronization protocol, which is out of scope 3594 for this specification). In this case, the loss of association would 3595 mean that communication with the entire multicast group of CEs has 3596 been lost. The mechanisms described above will apply for this case 3597 as well during the loss of association. If, however, the secondary 3598 CE was also using the multicast CE ID that was lost, then the FE will 3599 need to form a new association using a different CE ID. If the 3600 capability exists, the FE MAY first attempt to form a new association 3601 with original primary CE using a different non multicast CE ID. 3603 8.2. Responsibilities for HA 3605 TML Level: 3607 1. The TML controls logical connection availability and failover. 3609 2. The TML also controls peer HA management. 3611 At this level, control of all lower layers, for example transport 3612 level (such as IP addresses, MAC addresses etc) and associated links 3613 going down are the role of the TML. 3615 PL Level: 3616 All other functionality, including configuring the HA behavior during 3617 setup, the CE IDs used to identify primary and secondary CEs, 3618 protocol messages used to report CE failure (Event Report), Heartbeat 3619 messages used to detect association failure, messages to change the 3620 primary CE (Config), and other HA related operations described 3621 before, are the PL responsibility. 3623 To put the two together, if a path to a primary CE is down, the TML 3624 would take care of failing over to a backup path, if one is 3625 available. If the CE is totally unreachable then the PL would be 3626 informed and it would take the appropriate actions described before. 3628 9. Security Considerations 3630 ForCES architecture identifies several levels of security in 3631 [RFC3746]. ForCES PL uses security services provided by the ForCES 3632 TML. The TML provides security services such as endpoint 3633 authentication service, message authentication service and 3634 confidentiality service. Endpoint authentication service is invoked 3635 at the time of the pre-association connection establishment phase and 3636 message authentication is performed whenever the FE or CE receives a 3637 packet from its peer. 3639 The following are the general security mechanisms that need to be in 3640 place for ForCES PL. 3642 o Security mechanisms are session controlled - that is, once the 3643 security is turned on depending upon the chosen security level (No 3644 Security, Authentication, Confidentiality), it will be in effect 3645 for the entire duration of the session. 3647 o An operator should configure the same security policies for both 3648 primary and backup FEs and CEs (if available). This will ensure 3649 uniform operations and avoid unnecessary complexity in policy 3650 configuration. 3652 9.1. No Security 3654 When "No security" is chosen for ForCES protocol communication, both 3655 endpoint authentication and message authentication service needs to 3656 be performed by ForCES PL. Both these mechanism are weak and do not 3657 involve cryptographic operation. An operator can choose "No 3658 Security" level when the ForCES protocol endpoints are within a 3659 single box, for example. 3661 In order to have interoperable and uniform implementation across 3662 various security levels, each CE and FE endpoint MUST implement this 3663 level. 3665 9.1.1. Endpoint Authentication 3667 Each CE and FE PL maintains a list of associations as part its of 3668 configuration. This is done via the CEM and FEM interfaces. An FE 3669 MUST connect to only those CEs that are configured via the FEM; 3670 similarly, a CE should accept the connection and establish 3671 associations for the FEs which are configured via the CEM. The CE 3672 should validate the FE identifier before accepting the connections 3673 during the pre-association phase. 3675 9.1.2. Message authentication 3677 When a CE or FE initiates a message, the receiving endpoint MUST 3678 validate the initiator of the message by checking the common header 3679 CE or FE identifiers. This will ensure proper protocol functioning. 3680 This extra processing step is recommend even when underlying provides 3681 TLM layer security services exist. 3683 9.2. ForCES PL and TML security service 3685 This section is applicable if an operator wishes to use the TML 3686 security services. A ForCES TML MUST support one or more security 3687 services such as endpoint authentication service, message 3688 authentication service, and confidentiality service, as part of TML 3689 security layer functions. It is the responsibility of the operator 3690 to select an appropriate security service and configure security 3691 policies accordingly. The details of such configuration are outside 3692 the scope of the ForCES PL and are dependent on the type of transport 3693 protocol and the nature of the connection. 3695 All these configurations should be done prior to starting the CE and 3696 FE. 3698 When certificates-based authentication is being used at the TML, the 3699 certificate can use a ForCES-specific naming structure as certificate 3700 names and, accordingly, the security policies can be configured at 3701 the CE and FE. 3703 9.2.1. Endpoint authentication service 3705 When TML security services are enabled, the ForCES TML performs 3706 endpoint authentication. Security association is established between 3707 CE and FE and is transparent to the ForCES PL. 3709 9.2.2. Message authentication service 3711 This is a TML specific operation and is transparent to the ForCES PL. 3712 For details, refer to Section 5. 3714 9.2.3. Confidentiality service 3716 This is a TML specific operation and is transparent to the ForCES PL. 3717 For details, refer to Section 5. 3719 10. Acknowledgments 3721 The authors of this draft would like to acknowledge and thank the 3722 ForCES Working Group and especially the following: Furquan Ansari, 3723 Alex Audu, Steven Blake, Shuchi Chawla, Alan DeKok, Ellen M. 3724 Deleganes, Xiaoyi Guo, Yunfei Guo, Evangelos Haleplidis, Joel M. 3725 Halpern (who should probably be listed among the authors), Zsolt 3726 Haraszti, Fenggen Jia, John C. Lin, Alistair Munro, Jeff Pickering, 3727 T. Sridhlar, Guangming Wang, Chaoping Wu, and Lily L. Yang, for their 3728 contributions. We would also like to thank David Putzolu, and 3729 Patrick Droz for their comments and suggestions on the protocol and 3730 for their infinite patience. We would also like to thank Sue Hares 3731 and Alia Atlas for extensive reviews of the document. 3733 Alia Atlas has done a wonderful job of shaping the draft to make it 3734 more readable by providing the IESG feedback. 3736 The editors have used the xml2rfc [RFC2629] tools in creating this 3737 document and are very grateful for the existence and quality of these 3738 tools. The editor is also grateful to Elwyn Davies for his help in 3739 correcting the XML source of this document. 3741 11. References 3743 11.1. Normative References 3745 [FE-MODEL] 3746 Yang, L., Halpern, J., Gopal, R., DeKok, A., Haraszti, Z., 3747 and S. Blake, "ForCES Forwarding Element Model", 3748 Feb. 2005. 3750 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 3751 Requirement Levels", BCP 14, RFC 2119, March 1997. 3753 [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an 3754 IANA Considerations Section in RFCs", BCP 26, RFC 2434, 3755 October 1998. 3757 11.2. Informational References 3759 [2PCREF] Gray, J., "Notes on database operating systems. In 3760 Operating Systems: An Advanced Course. Lecture Notes in 3761 Computer Science, Vol. 60, pp. 394-481, Springer-Verlag", 3762 1978. 3764 [ACID] Haerder, T. and A. Reuter, "Principles of Transaction- 3765 Orientated Database Recovery", 1983. 3767 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 3768 June 1999. 3770 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 3771 of IP Control and Forwarding", RFC 3654, November 2003. 3773 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 3774 "Forwarding and Control Element Separation (ForCES) 3775 Framework", RFC 3746, April 2004. 3777 Appendix A. IANA Considerations 3779 Following the policies outlined in "Guidelines for Writing an IANA 3780 Considerations Section in RFCs" (RFC 2434 [RFC2434]), the following 3781 name spaces are defined in ForCES. 3783 o Message Type Name Space Section 7 3785 o Operation Type Name Space Section 7.1.6 3787 o Header Flags Section 6.1 3789 o TLV Type Section 7 3791 o TLV Result Values Section 7.1.7 3793 o LFB Class ID Section 7.1.5 3795 o Result: Association Setup Response Section 7.5.2 3797 o Reason: Association Teardown Message Section 7.5.3 3799 A.1. Message Type Name Space 3801 The Message Type is an 8 bit value. The following is the guideline 3802 for defining the Message Type namespace 3804 Message Types 0x00 - 0x0F 3805 Message Types in this range are part of the base ForCES Protocol. 3806 Message Types in this range are allocated through an IETF 3807 consensus action. [RFC2434] 3808 Values assigned by this specification: 3810 0x00 Reserved 3811 0x01 AssociationSetup 3812 0x02 AssociationTeardown 3813 0x03 Config 3814 0x04 Query 3815 0x05 EventNotification 3816 0x06 PacketRedirect 3817 0x07 - 0x0E Reserved 3818 0x0F Hearbeat 3819 0x11 AssociationSetupRepsonse 3820 0x12 Reserved 3821 0x13 ConfigRepsonse 3822 0x14 QueryResponse 3824 Message Types 0x20 - 0x7F 3825 Message Types in this range are Specification Required [RFC2434] 3826 Message Types using this range must be documented in an RFC or 3827 other permanent and readily available reference. 3829 Message Types 0x80 - 0xFF 3830 Message Types in this range are reserved for vendor private 3831 extensions and are the responsibility of individual vendors. IANA 3832 management of this range of the Message Type Name Space is 3833 unnecessary. 3835 A.2. Operation Selection 3837 The Operation Selection (OPER-TLV) name space is 16 bits long. The 3838 following is the guideline for managing the OPER-TLV Name Space. 3840 OPER-TLV Type 0x0000-0x00FF 3841 OPER-TLV Types in this range are allocated through an IETF 3842 consensus process. [RFC2434]. 3843 Values assigned by this specification: 3845 0x0000 Reserved 3846 0x0001 SET 3847 0x0002 SET-PROP 3848 0x0003 SET-RESPONSE 3849 0x0004 SET-PROP-RESPONSE 3850 0x0005 DEL 3851 0x0006 DEL-RESPONSE 3852 0x0007 GET 3853 0x0008 GET-PROP 3854 0x0009 GET-RESPONSE 3855 0x000A GET-PROP-RESPONSE 3856 0x000B REPORT 3857 0x000C COMMIT 3858 0x000D COMMIT-RESPONSE 3859 0x000E TRCOMP 3861 OPER-TLV Type 0x0100-0x7FFF 3862 OPER-TLV Types using this range must be documented in an RFC or 3863 other permanent and readily available reference. [RFC2434]. 3865 OPER-TLV Type 0x8000-0xFFFF 3866 OPER-TLV Types in this range are reserved for vendor private 3867 extensions and are the responsibility of individual vendors. IANA 3868 management of this range of the OPER-TLV Type Name Space is 3869 unnecessary. 3871 A.3. Header Flags 3873 The Header flag field is 32 bits long. Header flags are part of 3874 the ForCES base protocol. Header flags are allocated through an 3875 IETF consensus action [RFC2434]. 3877 A.4. TLV Type Name Space 3879 The TLV Type name space is 16 bits long. The following is the 3880 guideline for managing the TLV Type Name Space. 3882 TLV Type 0x0000-0x00FF 3883 TLV Types in this range are allocated through an IETF consensus 3884 process. [RFC2434]. 3885 Values assigned by this specification: 3887 0x0000 Reserved 3888 0x0001 REDIRECT-TLV 3889 0x0010 ASResult-TLV 3890 0x0011 ASTreason-TLV 3891 0x1000 LFBselect-TLV 3892 0x0110 PATH-DATA-TLV 3893 0x0111 KEYINFO-TLV 3894 0x0112 FULLDATA-TLV 3895 0x0113 SPARSEDATA-TLV 3896 0x0114 RESULT-TLV 3897 0x0115 METADATA-TLV 3898 0x0116 REDIRECTDATA-TLV 3900 TLV Type 0x0200-0x7FFF 3901 TLV Types using this range must be documented in an RFC or other 3902 permanent and readily available reference [RFC2434]. 3904 TLV Type 0x8000-0xFFFF 3905 TLV Types in this range are reserved for vendor private extensions 3906 and are the responsibility of individual vendors. IANA management 3907 of this range of the TLV Type Name Space is unnecessary. 3909 A.5. Result-TLV Result Values 3911 The RESULT-TLV RTesult Value is an 8 bit value. 3913 0x00 E_SUCCESS 3914 0x01 E_INVALID_HEADER 3915 0x02 E_LENGTH_MISMATCH 3916 0x03 E_VERSION_MISMATCH 3917 0x04 E_INVALID_DESTINATION_PID 3918 0x05 E_LFB_UNKNOWN 3919 0x06 E_LFB_NOT_FOUND 3920 0x07 E_LFB_INSTANCE_ID_NOT_FOUND 3921 0x08 E_INVALID_PATH 3922 0x09 E_ELEMENT_DOES_NOT_EXIST 3923 0x0A E_EXISTS 3924 0x0B E_NOT_FOUND 3925 0x0C E_READ_ONLY 3926 0x0D E_INVALID_ARRAY_CREATION 3927 0x0E E_VALUE_OUT_OF_RANGE 3928 0x0F E_CONTENTS_TOO_LONG 3929 0x10 E_INVALID_PARAMETERS 3930 0x11 E_INVALID_MESSAGE_TYPE 3931 0x12 E_E_INVALID_FLAGS 3932 0x13 E_INVALID_TLV 3933 0x14 E_EVENT_ERROR 3934 0x15 E_NOT_SUPPORTED 3935 0x16 E_MEMORY_ERROR 3936 0x17 E_INTERNAL_ERROR 3937 0x18-0xFE Reserved 3938 0xFF E_UNSPECIFIED_ERROR 3940 All values not assigned in this specification are designated as 3941 Assignment by Expert review. 3943 A.6. Association Setup Response 3945 The Association Setup Response name space is 32 bits long. The 3946 following is the guideline for managing the Association Setup 3947 Response Name Space. 3949 Association Setup Response 0x0000-0x00FF 3950 Association Setup Responses in this range are allocated through an 3951 IETF consensus process [RFC2434]. 3952 Values assigned by this specification: 3954 0x0000 Success 3955 0x0001 FE ID Invalid 3956 0x0002 Permission Denied 3958 Association Setup Response 0x0100-0x0FFF 3959 Association Setup Responses in this range are Specification 3960 Required [RFC2434] Values using this range must be documented in 3961 an RFC or other permanent and readily available reference 3962 [RFC2434]. 3964 Association Setup Response 0x1000-0xFFFFFFFFF 3965 Association Setup Responses in this range are reserved for vendor 3966 private extensions and are the responsibility of individual 3967 vendors. IANA management of this range of the Association Setup 3968 Responses Name Space is unnecessary. 3970 A.7. Association Teardown Message 3972 The Association Teardown Message name space is 32 bits long. The 3973 following is the guideline for managing the Association Teardown 3974 Message Name Space. 3976 Association Teardown Message 0x00000000-0x0000FFFF 3977 Association Teardown Messages in this range are allocated through 3978 an IETF consensus process [RFC2434]. 3979 Values assigned by this specification: 3981 0x00000000 Normal - Teardown by Administrator 3982 0x00000001 Error - loss of heartbeats 3983 0x00000002 Error - loss of bandwidth 3984 0x00000003 Error - Out of Memory 3985 0x00000004 Error - Application Crash 3986 0x000000FF Error - Unspecified 3988 Association Teardown Message 0x00010000-0x7FFFFFFF 3989 Association Teardown Messages in this range are Specification 3990 Required [RFC2434] Association Teardown Messages using this range 3991 must be documented in an RFC or other permanent and readily 3992 available references. [RFC2434]. 3994 Association Teardown Message 0x80000000-0xFFFFFFFFF 3995 Association Teardown Messages in this range are reserved for 3996 vendor private extensions and are the responsibility of individual 3997 vendors. IANA management of this range of the Association 3998 Teardown Message Name Space is unnecessary. 4000 Appendix B. ForCES Protocol LFB schema 4002 The schema described below conforms to the LFB schema described in 4003 ForCES Model draft. [FE-MODEL] 4005 Section 7.3.1 describes the details of the different attributes 4006 defined in this definition. 4008 4013 4014 4015 4016 CEHBPolicyValues 4017 4018 The possible values of CE heartbeat policy 4019 4020 4021 uchar 4022 4023 4024 CEHBPolicy0 4025 4026 The CE heartbeat policy 0 4027 4028 4029 4030 CEHBPolicy1 4031 4032 The CE heartbeat policy 1 4033 4034 4035 4036 4037 4039 4040 FEHBPolicyValues 4041 4042 The possible values of FE heartbeat policy 4043 4044 4045 uchar 4046 4047 4048 FEHBPolicy0 4049 4050 The FE heartbeat policy 0 4051 4052 4053 4054 FEHBPolicy1 4055 4056 The FE heartbeat policy 1 4057 4058 4059 4060 4061 4063 4064 FERestartPolicyValues 4065 4066 The possible values of FE restart policy 4067 4068 4069 uchar 4070 4071 4072 FERestartPolicy0 4073 4074 The FE restart policy 0 4075 4076 4077 4078 4079 4081 4082 CEFailoverPolicyValues 4083 4084 The possible values of CE failover policy 4085 4086 4087 uchar 4088 4089 4090 CEFailoverPolicy0 4091 4092 The CE failover policy 0 4093 4094 4096 4097 CEFailoverPolicy1 4098 4099 The CE failover policy 1 4100 4101 4102 4103 4104 4106 4107 FEHACapab 4108 4109 The supported HA features 4110 4111 4112 uchar 4113 4114 4115 GracefullRestart 4116 4117 The FE supports Graceful Restart 4118 4119 4120 4121 HA 4122 4123 The FE supports HA 4124 4125 4126 4127 4128 4129 4131 4132 4133 FEPO 4134 4135 The FE Protocol Object 4136 4137 1.0 4139 4140 4141 CurrentRunningVersion 4142 Currently running ForCES version 4143 u8 4145 4146 4147 FEID 4148 Unicast FEID 4149 uint32 4150 4151 4152 MulticastFEIDs 4153 4154 the table of all multicast IDs 4155 4156 4157 uint32 4158 4159 4160 4161 CEHBPolicy 4162 4163 The CE Heartbeat Policy 4164 4165 CEHBPolicyValues 4166 4167 4168 CEHDI 4169 4170 The CE Heartbeat Dead Interval in millisecs 4171 4172 uint32 4173 4174 4175 FEHBPolicy 4176 4177 The FE Heartbeat Policy 4178 4179 FEHBPolicyValues 4180 4181 4182 FEHI 4183 4184 The FE Heartbeat Interval in millisecs 4185 4186 uint32 4187 4188 4189 CEID 4190 4191 The Primary CE this FE is associated with 4192 4193 uint32 4194 4195 4196 BackupCEs 4197 4198 The table of all backup CEs other than the primary 4199 4200 4201 uint32 4202 4203 4204 4205 CEFailoverPolicy 4206 4207 The CE Failover Policy 4208 4209 CEFailoverPolicyValues 4210 4212 4213 CEFTI 4214 4215 The CE Failover Timeout Interval in millisecs 4216 4217 uint32 4218 4219 4220 FERestartPolicy 4221 4222 The FE Restart Policy 4223 4224 FERestartPolicyValues 4225 4226 4227 LastCEID 4228 4229 The Primary CE this FE was last associated with 4230 4231 uint32 4232 4233 4235 4236 4237 SupportableVersions 4238 4239 the table of ForCES versions that FE supports 4240 4241 4242 u8 4243 4244 4245 4246 HACapabilities 4247 4248 the table of HA capabilities the FE supports 4249 4250 4251 FEHACapab 4252 4253 4254 4256 4257 4258 PrimaryCEDown 4259 4260 The pimary CE has changed 4261 4262 4263 LastCEID 4264 4265 4266 4267 4268 LastCEID 4269 4270 4271 4272 4274 4275 4276 4278 B.1. Capabilities 4280 Supportable Versions enumerates all ForCES versions that an FE 4281 supports. 4283 FEHACapab enumerates the HA capabilities of the FE. If the FE is not 4284 capable of Graceful restarts or HA, then it will not be able to 4285 participate in HA as described in Section 8.1 4287 B.2. Attributes 4289 All Attributes are explained in Section 7.3.1. 4291 Appendix C. Data Encoding Examples 4293 In this section a few examples of data encoding are discussed. these 4294 example, however, do not show any padding. 4296 ========== 4297 Example 1: 4298 ========== 4300 Structure with three fixed-lengthof, mandatory fields. 4302 struct S { 4303 uint16 a 4304 uint16 b 4305 uint16 c 4306 } 4308 (a) Describing all fields using SPARSEDATA 4310 Path-Data TLV 4311 Path to an instance of S ... 4312 SPARSEDATA TLV 4313 ElementIDof(a), lengthof(a), valueof(a) 4314 ElementIDof(b), lengthof(b), valueof(b) 4315 ElementIDof(c), lengthof(c), valueof(c) 4317 (b) Describing a subset of fields 4319 Path-Data TLV 4320 Path to an instance of S ... 4321 SPARSEDATA TLV 4322 ElementIDof(a), lengthof(a), valueof(a) 4323 ElementIDof(c), lengthof(c), valueof(c) 4325 Note: Even though there are non-optional elements in structure S, 4326 since one can uniquely identify elements, one can selectively send 4327 element of structure S (eg in the case of an update from CE to FE). 4329 (c) Describing all fields using a FULLDATA TLV 4331 Path-Data TLV 4332 Path to an instance of S ... 4333 FULLDATA TLV 4334 valueof(a) 4335 valueof(b) 4336 valueof(c) 4338 ========== 4339 Example 2: 4340 ========== 4342 Structure with three fixed-lengthof fields, one mandatory, two 4343 optional. 4345 struct T { 4346 uint16 a 4347 uint16 b (optional) 4348 uint16 c (optional) 4349 } 4351 This example is identical to Example 1, as illustrated below. 4353 (a) Describing all fields using SPARSEDATA 4355 Path-Data TLV 4356 Path to an instance of S ... 4357 SPARSEDATA TLV 4358 ElementIDof(a), lengthof(a), valueof(a) 4359 ElementIDof(b), lengthof(b), valueof(b) 4360 ElementIDof(c), lengthof(c), valueof(c) 4362 (b) Describing a subset of fields using SPARSEDATA 4364 Path-Data TLV 4365 Path to an instance of S ... 4366 SPARSEDATA TLV 4367 ElementIDof(a), lengthof(a), valueof(a) 4368 ElementIDof(c), lengthof(c), valueof(c) 4370 (c) Describing all fields using a FULLDATA TLV 4372 Path-Data TLV 4373 Path to an instance of S ... 4374 FULLDATA TLV 4375 valueof(a) 4376 valueof(b) 4377 valueof(c) 4379 Note: FULLDATA TLV _cannot_ be used unless all fields are being 4380 described. 4382 ========== 4383 Example 3: 4384 ========== 4385 Structure with a mix of fixed-lengthof and variable-lengthof fields, 4386 some mandatory, some optional. Note in this case, b is variable 4387 sized 4389 struct U { 4390 uint16 a 4391 string b (optional) 4392 uint16 c (optional) 4393 } 4395 (a) Describing all fields using SPARSEDATA 4397 Path to an instance of U ... 4398 SPARSEDATA TLV 4399 ElementIDof(a), lengthof(a), valueof(a) 4400 ElementIDof(b), lengthof(b), valueof(b) 4401 ElementIDof(c), lengthof(c), valueof(c) 4403 (b) Describing a subset of fields using SPARSEDATA 4405 Path to an instance of U ... 4406 SPARSEDATA TLV 4407 ElementIDof(a), lengthof(a), valueof(a) 4408 ElementIDof(c), lengthof(c), valueof(c) 4410 (c) Describing all fields using FULLDATA TLV 4412 Path to an instance of U ... 4413 FULLDATA TLV 4414 valueof(a) 4415 FULLDATA TLV 4416 valueof(b) 4417 valueof(c) 4419 Note: The variable-length field requires the addition of a FULLDATA 4420 TLV within the outer FULLDATA TLV as in the case of element b above. 4422 ========== 4423 Example 4: 4424 ========== 4426 Structure containing an array of another structure type. 4428 struct V { 4429 uint32 x 4430 uint32 y 4431 struct U z[] 4432 } 4434 (a) Encoding using SPARSEDATA, with two instances of z[], also 4435 described with SPARSEDATA, assuming only the 10th and 15th subscript 4436 of z[] are encoded. 4438 path to instance of V ... 4439 SPARSEDATA TLV 4440 ElementIDof(x), lengthof(x), valueof(x) 4441 ElementIDof(y), lengthof(y), valueof(y) 4442 ElementIDof(z), lengthof(all below) 4443 ElementID = 10 (i.e index 10 from z[]), lengthof(all below) 4444 ElementIDof(a), lengthof(a), valueof(a) 4445 ElementIDof(b), lengthof(b), valueof(b) 4446 ElementID = 15 (index 15 from z[]), lengthof(all below) 4447 ElementIDof(a), lengthof(a), valueof(a) 4448 ElementIDof(c), lengthof(c), valueof(c) 4450 Note the holes in the elements of z (10 followed by 15). Also note 4451 the gap in index 15 with only elements a and c appearing but not b. 4453 Appendix D. Use Cases 4455 Assume LFB with following attributes for the following use cases. 4457 foo1, type u32, ID = 1 4459 foo2, type u32, ID = 2 4461 table1: type array, ID = 3 4462 elements are: 4463 t1, type u32, ID = 1 4464 t2, type u32, ID = 2 // index into table 2 4465 KEY: nhkey, ID = 1, V = t2 4467 table2: type array, ID = 4 4468 elements are: 4469 j1, type u32, ID = 1 4470 j2, type u32, ID = 2 4471 KEY: akey, ID = 1, V = { j1,j2 } 4473 table3: type array, ID = 5 4474 elements are: 4475 someid, type u32, ID = 1 4476 name, type string variable sized, ID = 2 4478 table4: type array, ID = 6 4479 elements are: 4480 j1, type u32, ID = 1 4481 j2, type u32, ID = 2 4482 j3, type u32, ID = 3 4483 j4, type u32, ID = 4 4484 KEY: mykey, ID = 1, V = { j1} 4486 table5: type array, ID = 7 4487 elements are: 4488 p1, type u32, ID = 1 4489 p2, type array, ID = 2, array elements of type-X 4491 Type-X: 4492 x1, ID 1, type u32 4493 x2, ID2 , type u32 4494 KEY: tkey, ID = 1, V = { x1} 4496 All examples will use valueof(x) to indicate the value of the 4497 referenced attribute x. In the case where F_SEL** are missing (bits 4498 equal to 00) then the flags will not show any selection. 4500 All the examples only show use of FULLDATA for data encoding; 4501 although SPARSEDATA would make more sense in certain occasions, the 4502 emphasis is on showing the message layout. Refer to Appendix C for 4503 examples that show usage of both FULLDATA and SPARSEDATA. 4505 1. To get foo1 4507 OPER = GET-TLV 4508 Path-data TLV: IDCount = 1, IDs = 1 4509 Result: 4510 OPER = GET-RESPONSE-TLV 4511 Path-data-TLV: 4512 flags=0, IDCount = 1, IDs = 1 4513 FULLDATA-TLV L = 4+4, V = valueof(foo1) 4515 2. To set foo2 to 10 4517 OPER = SET-TLV 4518 Path-data-TLV: 4519 flags = 0, IDCount = 1, IDs = 2 4520 FULLDATA TLV: L = 4+4, V=10 4522 Result: 4523 OPER = SET-RESPONSE-TLV 4524 Path-data-TLV: 4525 flags = 0, IDCount = 1, IDs = 2 4526 RESULT-TLV 4528 3. To dump table2 4530 OPER = GET-TLV 4531 Path-data-TLV: 4532 IDCount = 1, IDs = 4 4533 Result: 4534 OPER = GET-RESPONSE-TLV 4535 Path-data-TLV: 4536 flags = 0, IDCount = 1, IDs = 4 4537 FULLDATA=TLV: L = XXX, V= 4538 a series of: index, valueof(j1), valueof(j2) 4539 representing the entire table 4541 Note: One should be able to take a GET-RESPONSE-TLV and 4542 convert it to a SET-TLV. If the result in the above example 4543 is sent back in a SET-TLV, (instead of a GET-RESPONSE_TLV) 4544 then the entire contents of the table will be replaced at 4545 that point. 4547 4. Multiple operations Example. To create entry 0-5 of table2 4548 (Error conditions are ignored) 4550 OPER = SET-TLV 4551 Path-data-TLV: 4552 flags = 0 , IDCount = 1, IDs=4 4553 PATH-DATA-TLV 4554 flags = 0, IDCount = 1, IDs = 0 4555 FULLDATA-TLV valueof(j1), valueof(j2) of entry 0 4556 PATH-DATA-TLV 4557 flags = 0, IDCount = 1, IDs = 1 4558 FULLDATA-TLV valueof(j1), valueof(j2) of entry 1 4559 PATH-DATA-TLV 4560 flags = 0, IDCount = 1, IDs = 2 4561 FULLDATA-TLV valueof(j1), valueof(j2) of entry 2 4562 PATH-DATA-TLV 4563 flags = 0, IDCount = 1, IDs = 3 4564 FULLDATA-TLV valueof(j1), valueof(j2) of entry 3 4565 PATH-DATA-TLV 4566 flags = 0, IDCount = 1, IDs = 4 4567 FULLDATA-TLV valueof(j1), valueof(j2) of entry 4 4568 PATH-DATA-TLV 4569 flags = 0, IDCount = 1, IDs = 5 4570 FULLDATA-TLV valueof(j1), valueof(j2) of entry 5 4572 Result: 4573 OPER = SET-RESPONSE-TLV 4574 Path-data-TLV: 4575 flags = 0 , IDCount = 1, IDs=4 4576 PATH-DATA-TLV 4577 flags = 0, IDCount = 1, IDs = 0 4578 RESULT-TLV 4579 PATH-DATA-TLV 4580 flags = 0, IDCount = 1, IDs = 1 4581 RESULT-TLV 4582 PATH-DATA-TLV 4583 flags = 0, IDCount = 1, IDs = 2 4584 RESULT-TLV 4585 PATH-DATA-TLV 4586 flags = 0, IDCount = 1, IDs = 3 4587 RESULT-TLV 4588 PATH-DATA-TLV 4589 flags = 0, IDCount = 1, IDs = 4 4590 RESULT-TLV 4591 PATH-DATA-TLV 4592 flags = 0, IDCount = 1, IDs = 5 4593 RESULT-TLV 4595 5. Block operations (with holes) example. Replace entry 0,2 of 4596 table2 4598 OPER = SET-TLV 4599 Path-data TLV: 4600 flags = 0 , IDCount = 1, IDs=4 4601 PATH-DATA-TLV 4602 flags = 0, IDCount = 1, IDs = 0 4603 FULLDATA-TLV containing valueof(j1), valueof(j2) of 0 4604 PATH-DATA-TLV 4605 flags = 0, IDCount = 1, IDs = 2 4606 FULLDATA-TLV containing valueof(j1), valueof(j2) of 2 4608 Result: 4609 OPER = SET-TLV 4610 Path-data TLV: 4611 flags = 0 , IDCount = 1, IDs=4 4612 PATH-DATA-TLV 4613 flags = 0, IDCount = 1, IDs = 0 4614 RESULT-TLV 4615 PATH-DATA-TLV 4616 flags = 0, IDCount = 1, IDs = 2 4617 RESULT-TLV 4619 6. Getting rows example. Get first entry of table2. 4621 OPER = GET-TLV 4622 Path-data TLV: 4623 IDCount = 2, IDs=4.0 4625 Result: 4626 OPER = GET-RESPONSE-TLV 4627 Path-data TLV: 4628 IDCount = 2, IDs=4.0 4629 FULLDATA-TLV containing valueof(j1), valueof(j2) 4631 7. Get entry 0-5 of table2. 4633 OPER = GET-TLV 4634 Path-data-TLV: 4635 flags = 0, IDCount = 1, IDs=4 4636 PATH-DATA-TLV 4637 flags = 0, IDCount = 1, IDs = 0 4638 PATH-DATA-TLV 4639 flags = 0, IDCount = 1, IDs = 1 4640 PATH-DATA-TLV 4641 flags = 0, IDCount = 1, IDs = 2 4642 PATH-DATA-TLV 4643 flags = 0, IDCount = 1, IDs = 3 4644 PATH-DATA-TLV 4645 flags = 0, IDCount = 1, IDs = 4 4646 PATH-DATA-TLV 4647 flags = 0, IDCount = 1, IDs = 5 4649 Result: 4650 OPER = GET-RESPONSE-TLV 4651 Path-data-TLV: 4652 flags = 0, IDCount = 1, IDs=4 4653 PATH-DATA-TLV 4654 flags = 0, IDCount = 1, IDs = 0 4655 FULLDATA-TLV containing valueof(j1), valueof(j2) 4656 PATH-DATA-TLV 4657 flags = 0, IDCount = 1, IDs = 1 4658 FULLDATA-TLV containing valueof(j1), valueof(j2) 4659 PATH-DATA-TLV 4660 flags = 0, IDCount = 1, IDs = 2 4661 FULLDATA-TLV containing valueof(j1), valueof(j2) 4662 PATH-DATA-TLV 4663 flags = 0, IDCount = 1, IDs = 3 4664 FULLDATA-TLV containing valueof(j1), valueof(j2) 4665 PATH-DATA-TLV 4666 flags = 0, IDCount = 1, IDs = 4 4667 FULLDATA-TLV containing valueof(j1), valueof(j2) 4668 PATH-DATA-TLV 4669 flags = 0, IDCount = 1, IDs = 5 4670 FULLDATA-TLV containing valueof(j1), valueof(j2) 4672 8. Create a row in table2, index 5. 4674 OPER = SET-TLV 4675 Path-data-TLV: 4676 flags = 0, IDCount = 2, IDs=4.5 4677 FULLDATA-TLV containing valueof(j1), valueof(j2) 4679 Result: 4680 OPER = SET-RESPONSE-TLV 4681 Path-data TLV: 4682 flags = 0, IDCount = 1, IDs=4.5 4683 RESULT-TLV 4685 9. Dump contents of table1. 4687 OPER = GET-TLV 4688 Path-data TLV: 4689 flags = 0, IDCount = 1, IDs=3 4691 Result: 4692 OPER = GET-RESPONSE-TLV 4693 Path-data TLV 4694 flags = 0, IDCount = 1, IDs=3 4695 FULLDATA TLV, Length = XXXX 4696 (depending on size of table1) 4697 index, valueof(t1),valueof(t2) 4698 index, valueof(t1),valueof(t2) 4699 . 4700 . 4701 . 4703 10. Using Keys. Get row entry from table4 where j1=100. Recall, j1 4704 is a defined key for this table and its KeyID is 1. 4706 OPER = GET-TLV 4707 Path-data-TLV: 4708 flags = F_SELKEY IDCount = 1, IDs=6 4709 KEYINFO-TLV = KeyID=1, KEY_DATA=100 4711 Result: 4712 If j1=100 was at index 10 4713 OPER = GET-RESPONSE-TLV 4714 Path-data TLV: 4715 flags = 0, IDCount = 1, IDs=6.10 4716 FULLDATA-TLV containing 4717 valueof(j1), valueof(j2),valueof(j3),valueof(j4) 4719 11. Delete row with KEY match (j1=100, j2=200) in table 2. Note 4720 that the j1,j2 pair are a defined key for the table 2. 4722 OPER = DEL-TLV 4723 Path-data TLV: 4724 flags = F_SELKEY IDCount = 1, IDs=4 4725 KEYINFO TLV: {KeyID =1 KEY_DATA=100,200} 4727 Result: 4728 If (j1=100, j2=200) was at entry 15: 4729 OPER = DELETE-RESPONSE-TLV 4730 Path-data TLV: 4731 flags = 0 IDCount = 2, IDs=4.15 4732 RESULT-TLV 4734 12. Dump contents of table3. It should be noted that this table has 4735 a column with element name that is variable sized. The purpose 4736 of this use case is to show how such an element is to be 4737 encoded. 4739 OPER = GET-TLV 4740 Path-data-TLV: 4741 flags = 0 IDCount = 1, IDs=5 4743 Result: 4744 OPER = GET-RESPONSE-TLV 4745 Path-data TLV: 4746 flags = 0 IDCount = 1, IDs=5 4747 FULLDATA TLV, Length = XXXX 4748 index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), 4749 V = valueof(v) 4750 index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), 4751 V = valueof(v) 4752 index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), 4753 V = valueof(v) 4754 index, someidv, TLV: T=FULLDATA, L = 4+strlen(namev), 4755 V = valueof(v) 4756 . 4757 . 4758 . 4760 13. Multiple atomic operations. 4762 Note 1: This emulates adding a new nexthop entry and then 4763 atomically updating the L3 entries pointing to an old NH to 4764 point to a new one. The assumption is both tables are in the 4765 same LFB 4767 Note2: Observe the two operations on the LFB instance, both 4768 are SET operations. 4770 //Operation 1: Add a new entry to table2 index #20. 4771 OPER = SET-TLV 4772 Path-TLV: 4773 flags = 0, IDCount = 2, IDs=4.20 4774 FULLDATA TLV, V= valueof(j1),valueof(j2) 4776 // Operation 2: Update table1 entry which 4777 // was pointing with t2 = 10 to now point to 20 4778 OPER = SET-TLV 4779 Path-data-TLV: 4780 flags = F_SELKEY, IDCount = 1, IDs=3 4781 KEYINFO = KeyID=1 KEY_DATA=10 4782 Path-data-TLV 4783 flags = 0 IDCount = 1, IDs=2 4784 FULLDATA TLV, V= 20 4786 Result: 4787 //first operation, SET 4788 OPER = SET-RESPONSE-TLV 4789 Path-data-TLV 4790 flags = 0 IDCount = 3, IDs=4.20 4791 RESULT-TLV code = success 4792 FULLDATA TLV, V = valueof(j1),valueof(j2) 4793 // second operation SET - assuming entry 16 was updated 4794 OPER = SET-RESPONSE-TLV 4795 Path-data TLV 4796 flags = 0 IDCount = 2, IDs=3.16 4797 Path-Data TLV 4798 flags = 0 IDCount = 1, IDs = 2 4799 SET-RESULT-TLV code = success 4800 FULLDATA TLV, Length = XXXX v=20 4802 14. Selective setting. On table 4 -- for indices 1, 3, 5, 7, and 9. 4803 Replace j1 to 100, j2 to 200, j3 to 300. Leave j4 as is. 4805 PER = SET-TLV 4806 Path-data TLV 4807 flags = 0, IDCount = 1, IDs = 6 4808 Path-data TLV 4809 flags = 0, IDCount = 1, IDs = 1 4810 Path-data TLV 4811 flags = 0, IDCount = 1, IDs = 1 4812 FULLDATA TLV, Length = XXXX, V = {100} 4813 Path-data TLV 4814 flags = 0, IDCount = 1, IDs = 2 4815 FULLDATA TLV, Length = XXXX, V = {200} 4816 Path-data TLV 4817 flags = 0, IDCount = 1, IDs = 3 4818 FULLDATA TLV, Length = XXXX, V = {300} 4819 Path-data TLV 4820 flags = 0, IDCount = 1, IDs = 3 4821 Path-data TLV 4822 flags = 0, IDCount = 1, IDs = 1 4823 FULLDATA TLV, Length = XXXX, V = {100} 4824 Path-data TLV 4825 flags = 0, IDCount = 1, IDs = 2 4826 FULLDATA TLV, Length = XXXX, V = {200} 4827 Path-data TLV 4828 flags = 0, IDCount = 1, IDs = 3 4829 FULLDATA TLV, Length = XXXX, V = {300} 4830 Path-data TLV 4831 flags = 0, IDCount = 1, IDs = 5 4832 Path-data TLV 4833 flags = 0, IDCount = 1, IDs = 1 4834 FULLDATA TLV, Length = XXXX, V = {100} 4835 Path-data TLV 4836 flags = 0, IDCount = 1, IDs = 2 4837 FULLDATA TLV, Length = XXXX, V = {200} 4838 Path-data TLV 4839 flags = 0, IDCount = 1, IDs = 3 4840 FULLDATA TLV, Length = XXXX, V = {300} 4841 Path-data TLV 4842 flags = 0, IDCount = 1, IDs = 7 4843 Path-data TLV 4844 flags = 0, IDCount = 1, IDs = 1 4845 FULLDATA TLV, Length = XXXX, V = {100} 4846 Path-data TLV 4847 flags = 0, IDCount = 1, IDs = 2 4848 FULLDATA TLV, Length = XXXX, V = {200} 4849 Path-data TLV 4850 flags = 0, IDCount = 1, IDs = 3 4851 FULLDATA TLV, Length = XXXX, V = {300} 4852 Path-data TLV 4853 flags = 0, IDCount = 1, IDs = 9 4854 Path-data TLV 4855 flags = 0, IDCount = 1, IDs = 1 4856 FULLDATA TLV, Length = XXXX, V = {100} 4857 Path-data TLV 4858 flags = 0, IDCount = 1, IDs = 2 4859 FULLDATA TLV, Length = XXXX, V = {200} 4860 Path-data TLV 4861 flags = 0, IDCount = 1, IDs = 3 4862 FULLDATA TLV, Length = XXXX, V = {300} 4864 response: 4866 OPER = SET-RESPONSE-TLV 4867 Path-data TLV 4868 flags = 0, IDCount = 1, IDs = 6 4869 Path-data TLV 4870 flags = 0, IDCount = 1, IDs = 1 4871 Path-data TLV 4872 flags = 0, IDCount = 1, IDs = 1 4873 RESULT-TLV 4874 Path-data TLV 4875 flags = 0, IDCount = 1, IDs = 2 4876 RESULT-TLV 4877 Path-data TLV 4878 flags = 0, IDCount = 1, IDs = 3 4879 RESULT-TLV 4880 Path-data TLV 4881 flags = 0, IDCount = 1, IDs = 3 4882 Path-data TLV 4883 flags = 0, IDCount = 1, IDs = 1 4884 RESULT-TLV 4885 Path-data TLV 4886 flags = 0, IDCount = 1, IDs = 2 4887 RESULT-TLV 4888 Path-data TLV 4889 flags = 0, IDCount = 1, IDs = 3 4890 RESULT-TLV 4891 Path-data TLV 4892 flags = 0, IDCount = 1, IDs = 5 4893 Path-data TLV 4894 flags = 0, IDCount = 1, IDs = 1 4895 RESULT-TLV 4896 Path-data TLV 4897 flags = 0, IDCount = 1, IDs = 2 4898 RESULT-TLV 4899 Path-data TLV 4900 flags = 0, IDCount = 1, IDs = 3 4901 RESULT-TLV 4902 Path-data TLV 4903 flags = 0, IDCount = 1, IDs = 7 4904 Path-data TLV 4905 flags = 0, IDCount = 1, IDs = 1 4906 RESULT-TLV 4907 Path-data TLV 4908 flags = 0, IDCount = 1, IDs = 2 4909 RESULT-TLV 4910 Path-data TLV 4911 flags = 0, IDCount = 1, IDs = 3 4912 RESULT-TLV 4913 Path-data TLV 4914 flags = 0, IDCount = 1, IDs = 9 4915 Path-data TLV 4916 flags = 0, IDCount = 1, IDs = 1 4917 RESULT-TLV 4918 Path-data TLV 4919 flags = 0, IDCount = 1, IDs = 2 4920 RESULT-TLV 4921 Path-data TLV 4922 flags = 0, IDCount = 1, IDs = 3 4923 RESULT-TLV 4925 15. Manipulation of table of table examples. Get x1 from table10 4926 row with index 4, inside table5 entry 10 4928 operation = GET-TLV 4929 Path-data-TLV 4930 flags = 0 IDCount = 5, IDs=7.10.2.4.1 4932 Results: 4933 operation = GET-RESPONSE-TLV 4934 Path-data-TLV 4935 flags = 0 IDCount = 5, IDs=7.10.2.4.1 4936 FULLDATA TLV: L=XXXX, V = valueof(x1) 4938 16. From table5's row 10 table10, get X2s based on on the value of 4939 x1 equaling 10 (recall x1 is KeyID 1) 4941 operation = GET-TLV 4942 Path-data-TLV 4943 flag = F_SELKEY, IDCount=3, IDS = 7.10.2 4944 KEYINFO TLV, KeyID = 1, KEYDATA = 10 4945 Path-data TLV 4946 IDCount = 1, IDS = 2 //select x2 4948 Results: 4949 If x1=10 was at entry 11: 4950 operation = GET-RESPONSE-TLV 4951 Path-data-TLV 4952 flag = 0, IDCount=5, IDS = 7.10.2.11 4953 Path-data TLV 4954 flags = 0 IDCount = 1, IDS = 2 4955 FULLDATA TLV: L=XXXX, V = valueof(x2) 4957 17. Further example of manipulating a table of tables 4959 Consider table 6 which is defined as: 4960 table6: type array, ID = 8 4961 elements are: 4962 p1, type u32, ID = 1 4963 p2, type array, ID = 2, array elements of type type-A 4965 type-A: 4966 a1, type u32, ID 1, 4967 a2, type array ID2 ,array elements of type type-B 4969 type-B: 4970 b1, type u32, ID 1 4971 b2, type u32, ID 2 4973 If for example one wanted to set by replacing: 4974 table6.10.p1 to 111 4975 table6.10.p2.20.a1 to 222 4976 table6.10.p2.20.a2.30.b1 to 333 4978 in one message and one operation. 4980 There are two ways to do this: 4981 a) using nesting 4982 b) using a flat path data 4984 A. Method using nesting 4985 in one message with a single operation 4987 operation = SET-TLV 4988 Path-data-TLV 4989 flags = 0 IDCount = 2, IDs=6.10 4990 Path-data-TLV 4991 flags = 0, IDCount = 1, IDs=1 4992 FULLDATA TLV: L=XXXX, 4993 V = {111} 4994 Path-data-TLV 4995 flags = 0 IDCount = 2, IDs=2.20 4996 Path-data-TLV 4997 flags = 0, IDCount = 1, IDs=1 4998 FULLDATA TLV: L=XXXX, 4999 V = {222} 5000 Path-data TLV : 5001 flags = 0, IDCount = 3, IDs=2.30.1 5002 FULLDATA TLV: L=XXXX, 5003 V = {333} 5004 Result: 5005 operation = SET-RESPONSE-TLV 5006 Path-data-TLV 5007 flags = 0 IDCount = 2, IDs=6.10 5008 Path-data-TLV 5009 flags = 0, IDCount = 1, IDs=1 5010 RESULT-TLV 5011 Path-data-TLV 5012 flags = 0 IDCount = 2, IDs=2.20 5013 Path-data-TLV 5014 flags = 0, IDCount = 1, IDs=1 5015 RESULT-TLV 5016 Path-data TLV : 5017 flags = 0, IDCount = 3, IDs=2.30.1 5018 RESULT-TLV 5020 B. Method using a flat path data in 5021 one message with a single operation 5023 operation = SET-TLV 5024 Path-data TLV : 5025 flags = 0, IDCount = 3, IDs=6.10.1 5026 FULLDATA TLV: L=XXXX, 5027 V = {111} 5028 Path-data TLV : 5029 flags = 0, IDCount = 5, IDs=6.10.1.20.1 5030 FULLDATA TLV: L=XXXX, 5031 V = {222} 5032 Path-data TLV : 5033 flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1 5034 FULLDATA TLV: L=XXXX, 5035 V = {333} 5036 Result: 5037 operation = SET-TLV 5038 Path-data TLV : 5039 flags = 0, IDCount = 3, IDs=6.10.1 5040 RESULT-TLV 5041 Path-data TLV : 5042 flags = 0, IDCount = 5, IDs=6.10.1.20.1 5043 RESULT-TLV 5044 Path-data TLV : 5045 flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1 5046 RESULT-TLV 5048 18. Get a whole LFB (all its attributes, etc.). 5050 For example: at startup a CE might well want the entire FE 5051 OBJECT LFB. So, in a request targeted at class 1, instance 5052 1, one might find: 5054 operation = GET-TLV 5055 Path-data-TLV 5056 flags = 0 IDCount = 0 5058 result: 5059 operation = GET-RESPONSE-TLV 5060 Path-data-TLV 5061 flags = 0 IDCount = 0 5062 FULLDATA encoding of the FE Object LFB 5064 Authors' Addresses 5066 Ligang Dong 5067 Zhejiang Gongshang University 5068 149 Jiaogong Road 5069 Hangzhou 310035 5070 P.R.China 5072 Phone: +86-571-88071024 5073 Email: donglg@mail.zjgsu.edu.cn 5075 Avri Doria 5076 Lulea University of Technology 5077 Rainbow Way 5078 Lulea SE-971 87 5079 Sweden 5081 Phone: +46 73 277 1788 5082 Email: avri@ltu.se 5084 Ram Gopal 5085 Nokia 5086 5, Wayside Road 5087 Burlington, MA 310035 5088 USA 5090 Phone: +1-781-993-3685 5091 Email: ram.gopal@nokia.com 5093 Robert Haas 5094 IBM 5095 Saumerstrasse 4 5096 8803 Ruschlikon 5097 Switzerland 5099 Phone: 5100 Email: rha@zurich.ibm.com 5101 Jamal Hadi Salim 5102 Znyx 5103 Ottawa, Ontario 5104 Canada 5106 Phone: 5107 Email: hadi@znyx.com 5109 Hormuzd M Khosravi 5110 Intel 5111 2111 NE 25th Avenue 5112 Hillsboro, OR 97124 5113 USA 5115 Phone: +1 503 264 0334 5116 Email: hormuzd.m.khosravi@intel.com 5118 Weiming Wang 5119 Zhejiang Gongshang University 5120 149 Jiaogong Road 5121 Hangzhou 310035 5122 P.R.China 5124 Phone: +86-571-88057712 5125 Email: wmwang@mail.zjgsu.edu.cn 5127 Full Copyright Statement 5129 Copyright (C) The IETF Trust (2007). 5131 This document is subject to the rights, licenses and restrictions 5132 contained in BCP 78, and except as set forth therein, the authors 5133 retain all their rights. 5135 This document and the information contained herein are provided on an 5136 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 5137 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 5138 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 5139 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 5140 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 5141 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 5143 Intellectual Property 5145 The IETF takes no position regarding the validity or scope of any 5146 Intellectual Property Rights or other rights that might be claimed to 5147 pertain to the implementation or use of the technology described in 5148 this document or the extent to which any license under such rights 5149 might or might not be available; nor does it represent that it has 5150 made any independent effort to identify any such rights. Information 5151 on the procedures with respect to rights in RFC documents can be 5152 found in BCP 78 and BCP 79. 5154 Copies of IPR disclosures made to the IETF Secretariat and any 5155 assurances of licenses to be made available, or the result of an 5156 attempt made to obtain a general license or permission for the use of 5157 such proprietary rights by implementers or users of this 5158 specification can be obtained from the IETF on-line IPR repository at 5159 http://www.ietf.org/ipr. 5161 The IETF invites any interested party to bring to its attention any 5162 copyrights, patents or patent applications, or other proprietary 5163 rights that may cover technology that may be required to implement 5164 this standard. Please address the information to the IETF at 5165 ietf-ipr@ietf.org. 5167 Acknowledgment 5169 Funding for the RFC Editor function is provided by the IETF 5170 Administrative Support Activity (IASA).