idnits 2.17.1 draft-ietf-forces-protocol-04.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 14. -- Found old boilerplate from RFC 3978, Section 5.5 on line 4032. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4004. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 4011. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4017. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 644: '...PL messages that MUST meet the ACIDity...' RFC 2119 keyword, line 705: '... records of the transaction MUST reply...' RFC 2119 keyword, line 857: '...e underlying TML MUST be capable of h...' RFC 2119 keyword, line 919: '... field. Senders SHOULD set it to zero...' RFC 2119 keyword, line 1016: '...tive, a particular multicast ID MAY be...' (17 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 510 has weird spacing: '...ing are scena...' == Line 857 has weird spacing: '...MUST be capab...' == Line 1269 has weird spacing: '...nt with the i...' == Line 1321 has weird spacing: '...is used with ...' == Line 2156 has weird spacing: '...data is a 'PA...' == (3 more instances...) -- 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 18, 2005) is 6858 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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 1144, but not defined == Missing Reference: 'SELECTOR' is mentioned on line 1145, but not defined -- Looks like a reference, but probably isn't: '101' on line 3074 -- Looks like a reference, but probably isn't: '200' on line 3074 == Unused Reference: 'RFC2629' is defined on line 2884, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2629 (Obsoleted by RFC 7749) ** Downref: Normative reference to an Informational RFC: RFC 3654 ** Downref: Normative reference to an Informational RFC: RFC 3746 Summary: 7 errors (**), 0 flaws (~~), 12 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Doria (editor) 3 Internet-Draft ETRI 4 Expires: January 19, 2006 July 18, 2005 6 ForCES Protocol Specification 7 draft-ietf-forces-protocol-04.txt 9 Status of this Memo 11 By submitting this Internet-Draft, each author represents that any 12 applicable patent or other IPR claims of which he or she is aware 13 have been or will be disclosed, and any of which he or she becomes 14 aware will be disclosed, in accordance with Section 6 of BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on January 19, 2006. 34 Copyright Notice 36 Copyright (C) The Internet Society (2005). 38 Abstract 40 This specification documents the Forwarding and Control Element 41 Separation protocol. This protocol is designed to be used between a 42 Control Element and a Forwarding Element in a Routing Network 43 Element. 45 Authors 47 The participants in the ForCES Protocol Team, co-authors and co- 48 editors, of this draft, are: 50 Ligang Dong (Zhejiang Gongshang University), Avri Doria (ETRI), Ram 51 Gopal (Nokia), Robert Haas (IBM), Jamal Hadi Salim (Znyx), Hormuzd M 52 Khosravi (Intel), and Weiming Wang (Zhejiang Gongshang University). 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1 Sections of this document . . . . . . . . . . . . . . . 4 58 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 3.1 Protocol Framework . . . . . . . . . . . . . . . . . . . 8 61 3.1.1 The PL layer . . . . . . . . . . . . . . . . . . . . 10 62 3.1.2 The TML layer . . . . . . . . . . . . . . . . . . . 11 63 3.1.3 The FEM/CEM Interface . . . . . . . . . . . . . . . 11 64 3.2 ForCES Protocol Phases . . . . . . . . . . . . . . . . . 12 65 3.2.1 Pre-association . . . . . . . . . . . . . . . . . . 12 66 3.2.2 Post-association . . . . . . . . . . . . . . . . . . 13 67 3.3 Protocol Mechanisms . . . . . . . . . . . . . . . . . . 14 68 3.3.1 Transactions, Atomicity, Execution and Responses . . 14 69 3.3.2 FE, CE, and FE protocol LFBs . . . . . . . . . . . . 17 70 3.3.3 Scaling by Concurrency . . . . . . . . . . . . . . . 18 71 4. TML Requirements . . . . . . . . . . . . . . . . . . . . . . 19 72 4.1 TML Parameterization . . . . . . . . . . . . . . . . . . 20 73 5. Message encapsulation . . . . . . . . . . . . . . . . . . . 21 74 5.1 Common Header . . . . . . . . . . . . . . . . . . . . . 21 75 5.2 Type Length Value . . . . . . . . . . . . . . . . . . . 24 76 5.2.1 Nested TLVs . . . . . . . . . . . . . . . . . . . . 25 77 5.2.2 Scope of the T in TLV . . . . . . . . . . . . . . . 25 78 6. Protocol Construction . . . . . . . . . . . . . . . . . . . 26 79 6.1 Protocol Grammar . . . . . . . . . . . . . . . . . . . . 26 80 6.1.1 Protocol BNF . . . . . . . . . . . . . . . . . . . . 26 81 6.1.2 Protocol Visualization . . . . . . . . . . . . . . . 30 82 6.2 Core ForCES LFBs . . . . . . . . . . . . . . . . . . . . 33 83 6.2.1 FE Protocol LFB . . . . . . . . . . . . . . . . . . 34 84 6.2.2 FE Object LFB . . . . . . . . . . . . . . . . . . . 35 85 6.3 Semantics of message Direction . . . . . . . . . . . . . 36 86 6.4 Association Messages . . . . . . . . . . . . . . . . . . 36 87 6.4.1 Association Setup Message . . . . . . . . . . . . . 36 88 6.4.2 Association Setup Response Message . . . . . . . . . 39 89 6.4.3 Association Teardown Message . . . . . . . . . . . . 41 90 6.5 Configuration Messages . . . . . . . . . . . . . . . . . 42 91 6.5.1 Config Message . . . . . . . . . . . . . . . . . . . 42 92 6.5.2 Config Response Message . . . . . . . . . . . . . . 45 93 6.6 Query and Query Response Messages . . . . . . . . . . . 47 94 6.6.1 Query Message . . . . . . . . . . . . . . . . . . . 47 95 6.6.2 Query Response Message . . . . . . . . . . . . . . . 49 96 6.7 Event Notification and Response Messages . . . . . . . . 50 97 6.7.1 Event Notification Message . . . . . . . . . . . . . 51 98 6.7.2 Event Notification Response Message . . . . . . . . 53 99 6.8 Packet Redirect Message . . . . . . . . . . . . . . . . 54 100 6.9 Heartbeat Message . . . . . . . . . . . . . . . . . . . 57 101 6.10 Operation Summary . . . . . . . . . . . . . . . . . . . 58 102 7. Protocol Scenarios . . . . . . . . . . . . . . . . . . . . . 60 103 7.1 Association Setup state . . . . . . . . . . . . . . . . 60 104 7.2 Association Established state or Steady State . . . . . 61 105 8. High Availability Support . . . . . . . . . . . . . . . . . 64 106 8.1 Responsibilities for HA . . . . . . . . . . . . . . . . 66 107 9. Security Considerations . . . . . . . . . . . . . . . . . . 68 108 9.1 No Security . . . . . . . . . . . . . . . . . . . . . . 68 109 9.1.1 Endpoint Authentication . . . . . . . . . . . . . . 68 110 9.1.2 Message authentication . . . . . . . . . . . . . . . 69 111 9.2 ForCES PL and TML security service . . . . . . . . . . . 69 112 9.2.1 Endpoint authentication service . . . . . . . . . . 69 113 9.2.2 Message authentication service . . . . . . . . . . . 69 114 9.2.3 Confidentiality service . . . . . . . . . . . . . . 70 115 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 71 116 11. References . . . . . . . . . . . . . . . . . . . . . . . . 72 117 11.1 Normative References . . . . . . . . . . . . . . . . . . 72 118 11.2 Informational References . . . . . . . . . . . . . . . . 72 119 Author's Address . . . . . . . . . . . . . . . . . . . . . . 72 120 A. Individual Authors/Editors Contact . . . . . . . . . . . . . 73 121 B. IANA considerations . . . . . . . . . . . . . . . . . . . . 75 122 C. Forces Protocol LFB schema . . . . . . . . . . . . . . . . . 76 123 C.1 Events . . . . . . . . . . . . . . . . . . . . . . . . . 77 124 C.2 Capabilities . . . . . . . . . . . . . . . . . . . . . . 77 125 C.3 Attributes . . . . . . . . . . . . . . . . . . . . . . . 77 126 C.3.1 HBI . . . . . . . . . . . . . . . . . . . . . . . . 77 127 C.3.2 HBDI . . . . . . . . . . . . . . . . . . . . . . . . 78 128 C.3.3 CurrentRunningVersion . . . . . . . . . . . . . . . 78 129 D. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . 79 130 E. Implementation Notes . . . . . . . . . . . . . . . . . . . . 95 131 E.1 TML considerations . . . . . . . . . . . . . . . . . . . 95 132 E.1.1 PL Flag inference by TML . . . . . . . . . . . . . . 95 133 E.1.2 Message type inference to Mapping at the TML . . . . 96 134 F. changes between -03 and -04 . . . . . . . . . . . . . . . . 98 135 G. changes between -02 and -03 . . . . . . . . . . . . . . . . 100 136 H. Changes between -01 and -02 . . . . . . . . . . . . . . . . 101 137 I. Changes between -00 and -01 . . . . . . . . . . . . . . . . 102 138 Intellectual Property and Copyright Statements . . . . . . . 103 140 1. Introduction 142 This specification provides a draft definition of an IP-based 143 protocol for Control Element control of an Forwarding Element. The 144 protocol is a TLV based protocol that include commands for transport 145 of LFB information as well as TLVs for association, configuration, 146 status, and events. 148 This specification does not specify a transport mechanism for 149 messages, but does include a discussion of the services that must be 150 provided by the transport interface. 152 1.1 Sections of this document 154 Section 2 provides a glossary of terminology used in the 155 specification. 157 Section 3 provides an overview of the protocol including a discussion 158 on the protocol framework, descriptions of the protocol layer (PL) 159 and a transport mapping layer (TML), as well as of the ForCES 160 protocol mechanisms. 162 While this document does not define the TML, Section 4 details the 163 services that the TML must provide. 165 The Forces protocol is defined to have a common header for all other 166 message types. The header is defined in Section 5.1, while the 167 protocol messages are defined in Section 6. 169 Section 7 describes several Protocol Scenarios and includes message 170 exchange descriptions. 172 Section 8 describes mechanism in the protocol to support high 173 availability mechanisms including redundancy and fail over. 174 Section 9 defines the security mechanisms provided by the PL and TML. 176 2. Definitions 178 This document follows the terminology defined by the ForCES 179 Requirements in [RFC3654] and by the ForCES framework in [RFC3746]. 180 This document also uses the terminology defined by ForCES FE model in 181 [FE-MODEL]. We copy the definitions of some of the terminology as 182 indicated below: 184 Addressable Entity (AE) - A physical device that is directly 185 addressable given some interconnect technology. For example, on IP 186 networks, it is a device to which we can communicate using an IP 187 address; and on a switch fabric, it is a device to which we can 188 communicate using a switch fabric port number. 190 Forwarding Element (FE) - A logical entity that implements the ForCES 191 protocol. FEs use the underlying hardware to provide per-packet 192 processing and handling as directed/controlled by a CE via the ForCES 193 protocol. 195 Control Element (CE) - A logical entity that implements the ForCES 196 protocol and uses it to instruct one or more FEs how to process 197 packets. CEs handle functionality such as the execution of control 198 and signaling protocols. 200 Pre-association Phase - The period of time during which a FE Manager 201 (see below) and a CE Manager (see below) are determining which FE and 202 CE should be part of the same network element. 204 Post-association Phase - The period of time during which a FE does 205 know which CE is to control it and vice versa, including the time 206 during which the CE and FE are establishing communication with one 207 another. 209 FE Model - A model that describes the logical processing functions 210 of a FE. 212 FE Manager (FEM) - A logical entity that operates in the pre- 213 association phase and is responsible for determining to which CE(s) a 214 FE should communicate. This process is called CE discovery and may 215 involve the FE manager learning the capabilities of available CEs. A 216 FE manager may use anything from a static configuration to a pre- 217 association phase protocol (see below) to determine which CE(s) to 218 use. Being a logical entity, a FE manager might be physically 219 combined with any of the other logical entities such as FEs. 221 CE Manager (CEM) - A logical entity that operates in the pre- 222 association phase and is responsible for determining to which FE(s) a 223 CE should communicate. This process is called FE discovery and may 224 involve the CE manager learning the capabilities of available FEs. A 225 CE manager may use anything from a static configuration to a pre- 226 association phase protocol (see below) to determine which FE to use. 227 Being a logical entity, a CE manager might be physically combined 228 with any of the other logical entities such as CEs. 230 ForCES Network Element (NE) - An entity composed of one or more CEs 231 and one or more FEs. To entities outside a NE, the NE represents a 232 single point of management. Similarly, a NE usually hides its 233 internal organization from external entities. 235 High Touch Capability - This term will be used to apply to the 236 capabilities found in some forwarders to take action on the contents 237 or headers of a packet based on content other than what is found in 238 the IP header. Examples of these capabilities include NAT-PT, 239 firewall, and L7 content recognition. 241 Datapath -- A conceptual path taken by packets within the forwarding 242 plane inside an FE. 244 LFB (Logical Function Block) type -- A template representing a fine- 245 grained, logically separable and well-defined processing operating 246 generally operating on packets in the datapath. LFB types are the 247 basic building blocks of the FE model. 249 LFB (Logical Function Block) Instance -- As a packet flows through an 250 FE along a datapath, it flows through one or multiple LFB instances, 251 with each implementing an instance of a certain LFB type. There may 252 be multiple instances of the same LFB in an FE's datapath. Note that 253 we often refer to LFBs without distinguishing between LFB type and 254 LFB instance when we believe the implied reference is obvious for the 255 given context. 257 LFB Metadata -- Metadata is used to communicate per-packet state from 258 one LFB to another, but is not sent across the network. The FE model 259 defines how such metadata is identified, produced and consumed by the 260 LFBs, but not how metadata is encoded within an implementation. 262 LFB Attribute -- Operational parameters of the LFBs that must be 263 visible to the CEs are conceptualized in the FE model as the LFB 264 attributes. The LFB attributes include, for example, flags, single 265 parameter arguments, complex arguments, and tables that the CE can 266 read or/and write via the ForCES protocol (see below). 268 LFB Topology -- Representation of how the LFB instances are logically 269 interconnected and placed along the datapath within one FE. 270 Sometimes it is also called intra-FE topology, to be distinguished 271 from inter-FE topology. 273 FE Topology -- A representation of how the multiple FEs within a 274 single NE are interconnected. Sometimes this is called inter-FE 275 topology, to be distinguished from intra-FE topology (i.e., LFB 276 topology). 278 Inter-FE Topology -- See FE Topology. 280 Intra-FE Topology -- See LFB Topology. 282 Following terminologies are defined by this document: 284 ForCES Protocol - While there may be multiple protocols used within 285 the overall ForCES architecture, the term "ForCES protocol" refers 286 only to the protocol used at the Fp reference point in the ForCES 287 Framework in RFC3746 [RFC3746]. This protocol does not apply to CE- 288 to-CE communication, FE-to-FE communication, or to communication 289 between FE and CE managers. Basically, the ForCES protocol works in 290 a master-slave mode in which FEs are slaves and CEs are masters. 291 This document defines the specifications for this ForCES protocol. 293 ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol 294 architecture that defines the ForCES protocol messages, the protocol 295 state transfer scheme, as well as the ForCES protocol architecture 296 itself (including requirements of ForCES TML (see below)). 297 Specifications of ForCES PL are defined by this document. 299 ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in 300 ForCES protocol architecture that specifically addresses the protocol 301 message transportation issues, such as how the protocol messages are 302 mapped to different transport media (like TCP, IP, ATM, Ethernet, 303 etc), and how to achieve and implement reliability, multicast, 304 ordering, etc. The ForCES TML is specifically addressed in a 305 separate ForCES TML Specification document. 307 3. Overview 309 The reader is referred to the Framework document [RFC3746], and in 310 particular sections 3 and 4, for an architectural overview and an 311 explanation of how the ForCES protocol fits in. There may be some 312 content overlap between the framework document and this section in 313 order to provide clarity. 315 3.1 Protocol Framework 317 Figure 1 below is reproduced from the Framework document for clarity. 318 It shows a NE with two CEs and two FEs. 320 --------------------------------------- 321 | ForCES Network Element | 322 -------------- Fc | -------------- -------------- | 323 | CE Manager |---------+-| CE 1 |------| CE 2 | | 324 -------------- | | | Fr | | | 325 | | -------------- -------------- | 326 | Fl | | | Fp / | 327 | | Fp| |----------| / | 328 | | | |/ | 329 | | | | | 330 | | | Fp /|----| | 331 | | | /--------/ | | 332 -------------- Ff | -------------- -------------- | 333 | FE Manager |---------+-| FE 1 | Fi | FE 2 | | 334 -------------- | | |------| | | 335 | -------------- -------------- | 336 | | | | | | | | | | 337 ----+--+--+--+----------+--+--+--+----- 338 | | | | | | | | 339 | | | | | | | | 340 Fi/f Fi/f 342 Fp: CE-FE interface 343 Fi: FE-FE interface 344 Fr: CE-CE interface 345 Fc: Interface between the CE Manager and a CE 346 Ff: Interface between the FE Manager and an FE 347 Fl: Interface between the CE Manager and the FE Manager 348 Fi/f: FE external interface 350 Figure 1: ForCES Architectural Diagram 352 The ForCES protocol domain is found in the Fp Reference Point. The 353 Protocol Element configuration reference points, Fc and Ff also play 354 a role in the booting up of the Forces Protocol. The protocol 355 element configuration is out of scope of the ForCES protocol but is 356 touched on in this document since it is an integral part of the 357 protocol pre-association phase. 359 Figure 2 below shows further breakdown of the Fp interface by example 360 of a MPLS QoS enabled Network Element. 362 ------------------------------------------------- 363 | | | | | | | 364 |OSPF |RIP |BGP |RSVP |LDP |. . . | 365 | | | | | | | 366 ------------------------------------------------- 367 | ForCES Interface | 368 ------------------------------------------------- 369 ^ ^ 370 | | 371 ForCES | |data 372 control | |packets 373 messages| |(e.g., routing packets) 374 | | 375 v v 376 ------------------------------------------------- 377 | ForCES Interface | 378 ------------------------------------------------- 379 | | | | | | | 380 |LPM Fwd|Meter |Shaper |MPLS |Classi-|. . . | 381 | | | | |fier | | 382 ------------------------------------------------- 384 Figure 2: Examples of CE and FE functions 386 The ForCES Interface shown in Figure 2 constitutes two pieces: the PL 387 and TML layer. 389 This is depicted in Figure 3 below. 391 +------------------------------------------------ 392 | CE PL layer | 393 +------------------------------------------------ 394 | CE TML layer | 395 +------------------------------------------------ 396 ^ 397 | 398 ForCES | (i.e Forces data + control 399 PL | packets ) 400 messages | 401 over | 402 specific | 403 TML | 404 encaps | 405 and | 406 transport | 407 | 408 v 409 +------------------------------------------------ 410 | FE TML layer | 411 +------------------------------------------------ 412 | FE PL layer | 413 +------------------------------------------------ 415 Figure 3: ForCES Interface 417 The PL layer is in fact the ForCES protocol. Its semantics and 418 message layout are defined in this document. The TML Layer is 419 necessary to connect two ForCES PL layers as shown in Figure 3 above. 420 The TML is out of scope for this document but is within scope of 421 ForCES. This document defines requirements the PL needs the TML to 422 meet. 424 Both the PL and the TML layers are standardized by the IETF. While 425 only one PL layer is defined, different TMLs are expected to be 426 standardized. To interoperate the TML layer at the CE and FE are 427 expected to conform to the same definition. 429 On transmit, the PL layer delivers its messages to the TML layer. 430 The TML layer delivers the message to the destination TML layer(s). 431 On receive, the TML delivers the message to its destination PL 432 layer(s). 434 3.1.1 The PL layer 436 The PL is common to all implementations of ForCES and is standardized 437 by the IETF as defined in this document. The PL layer is responsible 438 for associating an FE or CE to an NE. It is also responsible for 439 tearing down such associations. An FE uses the PL layer to throw 440 various subscribed-to events to the CE PL layer as well as respond to 441 various status requests issued from the CE PL. The CE configures 442 both the FE and associated LFBs attributes using the PL layer. In 443 addition the CE may send various requests to the FE to activate or 444 deactivate it, reconfigure its HA parametrization, subscribe to 445 specific events etc. More details in Section 6. 447 3.1.2 The TML layer 449 The TML layer is essentially responsible for transport of the PL 450 layer messages. The TML is where the issues of how to achieve 451 transport level reliability, congestion control, multicast, ordering, 452 etc are handled. It is expected more than one TML will be 453 standardized. The different TMLs each could implement things 454 differently based on capabilities of underlying media and transport. 455 However, since each TML is standardized, interoperability is 456 guaranteed as long as both endpoints support the same TML. All 457 ForCES Protocol Layer implementations should be portable across all 458 TMLs, because all TMLs have the same top edge semantics as defined in 459 this document. 461 3.1.3 The FEM/CEM Interface 463 The FEM and CEM components, although valuable in the setup and 464 configurations of both the PL and TML layers, are out of scope of the 465 ForCES protocol. The best way to think of them are as 466 configurations/parameterizations for the PL and TML before they 467 become active (or even at runtime based on implementation). In the 468 simplest case, the FE or CE read a static configuration file which 469 they use as the FEM/CEM interface. RFC 3746 has a lot more detailed 470 descriptions on how the FEM and CEM could be used. We discuss the 471 pre-association phase where the CEM and FEM play briefly in section 472 Section 3.2.1. 474 An example of typical things FEM/CEM would configure would be TML 475 specific parameterizations such as: 477 a. how the TML connection should happen (example what IP addresses 478 to use, transport modes etc); 480 b. the ID for the FE or CE would also be issued at this point. 482 c. Security parameterization such as keys etc. 484 d. Connection association parameters 486 Example "send up to 3 association messages each 1 second apart" Vs " 487 send up to 4 association messages with increasing exponential 488 timeout". 490 3.2 ForCES Protocol Phases 492 ForCES, in relation to NEs, involves two phases: the Pre-Association 493 phase where configuration/initialization/bootup of the TML and PL 494 layer happens, and the association phase where the ForCES protocol 495 operates. 497 3.2.1 Pre-association 499 The ForCES interface is configured during the pre-association phase. 500 In a simple setup, the configuration is static and is read from a 501 saved config file. All the parameters for the association phase are 502 well known after the pre-association phase is complete. A protocol 503 such as DHCP may be used to retrieve the config parameters instead of 504 reading them from a static config file. Note, this will still be 505 considered static pre-association. Dynamic configuration may also 506 happen using the Fc, Ff and Fl reference points. Vendors may use 507 their own proprietary service discovery protocol to pass the 508 parameters. 510 The following are scenarios reproduced from the Framework Document 511 to show a pre-association example. 513 <----Ff ref pt---> <--Fc ref pt-------> 514 FE Manager FE CE Manager CE 515 | | | | 516 | | | | 517 (security exchange) (security exchange) 518 1|<------------>| authentication 1|<----------->|authentication 519 | | | | 520 (FE ID, attributes) (CE ID, attributes) 521 2|<-------------| request 2|<------------|request 522 | | | | 523 3|------------->| response 3|------------>|response 524 (corresponding CE ID) (corresponding FE ID) 525 | | | | 526 | | | | 528 Figure 4: Examples of a message exchange over the Ff and Fc reference 529 points 531 <-----------Fl ref pt--------------> | 533 FE Manager FE CE Manager CE 534 | | | | 535 | | | | 536 (security exchange) | | 537 1|<------------------------------>| | 538 | | | | 539 (a list of CEs and their attributes) | 540 2|<-------------------------------| | 541 | | | | 542 (a list of FEs and their attributes) | 543 3|------------------------------->| | 544 | | | | 545 | | | | 547 Figure 5: An example of a message exchange over the Fl reference 548 point 550 Before the transition to the association phase, the FEM will have 551 established contact with the appropriate CEM component. 552 Initialization of the ForCES interface will be completed, and 553 authentication as well as capability discovery may be complete as 554 well. Both the FE and CE would have the necessary information for 555 connecting to each other for configuration, accounting, 556 identification and authentication purposes. Both sides also would 557 have all the necessary protocol parameters such as timers, etc. The 558 Fl reference point may continue to operate during the association 559 phase and may be used to force a disassociation of an FE or CE. 560 Because the pre-association phase is out of scope, these details are 561 not discussed any further in this specification. The reader is 562 referred to the framework document [RFC3746] for more detailed 563 discussion. 565 3.2.2 Post-association 567 In this phase, the FE and CE components communicate with each other 568 using the ForCES protocol (PL over TML) as defined in this document. 569 There are three sub-phases: 571 o Association setup state 573 o Established State 575 o Association teardown state. 577 3.2.2.1 Association setup state 579 The FE attempts to join the NE. The FE may be rejected or accepted. 580 Once granted access into the NE, capabilities exchange happens with 581 the CE querying the FE. Once the CE has the FE capability 582 information, the CE can offer an initial configuration (possibly to 583 restore state) and can query certain attributes within either an LFB 584 or the FE itself. 586 More details are provided in the protocol scenarios section. 588 On successful completion of this state, the FE joins the NE and is 589 moved to the Established State. 591 3.2.2.2 Association Established state 593 In this state the FE is continuously updated or queried. The FE may 594 also send asynchronous event notifications to the CE or synchronous 595 heartbeat notifications. This continues until a termination is 596 initiated by either the CE or the FE. 598 Refer to section on protocol scenarios Section 7 for more details. 600 3.3 Protocol Mechanisms 602 Various semantics are exposed to the protocol users via the PL header 603 including: Transaction capabilities, atomicity of transactions, two 604 phase commits, batching/parallelization, High Availability and 605 failover as well as command windows. 607 3.3.1 Transactions, Atomicity, Execution and Responses 609 In the master-slave relationship the CE instructs one or more FEs on 610 how to execute operations and how to report back the results. 612 This section details the different modes of execution that a CE can 613 order the FE(s) to perform in Section 3.3.1.1. It also describes the 614 different modes a CE can ask the FE(s) to format the responses back 615 after processing the operations requested. 617 3.3.1.1 Execution 619 There are 3 execution modes that could be requested for a batch of 620 operations spanning on one or more LFB selectors: 622 a. Transactional execute-all-or-none 623 b. Loose transactional execute-until-failure 625 c. Non-transactional continue-execute-on-failure 627 3.3.1.1.1 'all-or-none' Atomic transaction 629 A transaction maybe atomic: 631 a. Within an FE alone 632 Example: updating multiple tables which are dependent on each 633 other. If updating one fails, then any others already updated 634 must be undone. 636 b. Across the NE 637 Example: updating the same type of table(s) that are 638 interdependent across several FEs (such as L3 forwarding related 639 tables). 641 3.3.1.1.2 Transaction Definition 643 We define a transaction as a collection of one or more ForCES 644 operations within one or more PL messages that MUST meet the ACIDity 645 properties[ACID], defined as: 647 o *Atomicity*. In a transaction involving two or more discrete 648 pieces of information, either all of the pieces are committed or 649 none are. 651 o *Consistency*. A transaction either creates a new and valid state 652 of data, or, if any failure occurs, returns all data to its state 653 before the transaction was started. 655 o *Isolation*. A transaction in process and not yet committed must 656 remain isolated from any other transaction. 658 o *Durability*. Committed data is saved by the system such that, 659 even in the event of a failure and system restart, the data is 660 available in its correct state. 662 There are cases where the CE knows exact memory and implementation 663 details of the FE such as in the case of a FE-CE pair from the same 664 vendor where the FE-CE pair is tightly coupled. In such a case, the 665 transactional operations maybe simplified further by extra 666 computation at the CE. We do not discuss this view further other 667 than to mention it in not dissallowed. For the purpose of 668 interopability, we define a classical transactional protocol known as 669 two phase commit which meets the ACID properties to be used for 670 transactions. 672 3.3.1.1.3 Transaction protocol 674 A 2PC starts with a START | ATOMIC flag on its first message of a 675 transaction. A transaction may span multiple messages. It is up to 676 the CE to keep track of the different seq #s making up a transaction. 677 This may then be followed by more messages which are part of the same 678 atomic transaction. 680 Any failure notified by the FE causes the CE to execute an ABORT to 681 all FEs involved in the transaction, rolling back all previously 682 executed operations in the transaction. 684 The transaction commitment phase is signalled by an empty DONE msg 685 type. 687 3.3.1.1.4 Recovery 689 Any of the participating FEs, or the CE, or the associations between 690 them, may fail after the DONE message has left the CE and before it 691 has received all the responses, (possibly the DONE never reached the 692 FEs). At this point it is known that none of the operations failed 693 but it is presumed that the data has not yet been made durable by the 694 FEs. The means of detecting such failures may include loss of 695 heartbeat (within the scope of ForCES) or mechanisms outside the 696 scope of ForCES. When the associations are re-established, the CE 697 will discover a transaction in an intermediate state. Some FEs will 698 have made the data durable and closed the transaction; others may 699 have failed while doing so, and may, or may not, still have that 700 data. At this point the transaction enters the recovery phase. 702 The CE re-issues an empty DONE message to all FEs involved in the 703 transaction. Those that completed the transaction confirm this to 704 the CE. Those that did not, commit the data and confirm this to the 705 CE. An FE that has lost all records of the transaction MUST reply 706 with status UNKNOWN and the actions subsequently taken by the CE are 707 implementation dependent. 709 3.3.1.1.5 continue-execute-on-failure 711 In which several independent operations are targeted at one or more 712 LFB selectors. Execution continues at the FE when one or more 713 operations fail. This mode is signalled by a missing ATOMIC flag. 715 3.3.1.1.6 execute-until-falure 717 In which all operations are executed on FE sequentially until first 718 failure. The rest of the operations are not executed but everything 719 up to failed is not undone unlike the case of all-or-none execution. 721 flag: GOTON (global) 723 3.3.1.1.7 Relation to Multipart messages 725 Multipart flags apply. I.e all messages in a transaction except for 726 the last have a MULTIPART flag on. 728 There has to be consistency across the multi parts of the messages. 729 In other words the first message starting with mode #1 above, implies 730 the rest do. Any inconsitency implies a cancelled transaction in 731 which all messages are dropped and the sender NACKED. 733 3.3.2 FE, CE, and FE protocol LFBs 735 All PL messages operate on LFB structures as this provides more 736 flexibility for future enhancements. This means that maintenance and 737 configurability of FEs, NE, as well as the ForCES protocol itself 738 must be expressed in terms of this LFB architecture. For this reason 739 special LFBs are created to accomodate this need. 741 In addition, this shows how the ForCES protocol itself can be 742 controlled by the very same type of structures (LFBs) it uses to 743 control functions such as IP forwarding, filtering, etc. 745 To achieve this, the following LFBs are used: 747 o FE Protocol LFB 749 o FE LFB 751 These LFBs are detailed in Section 6.2. A short description is 752 provided here: 754 o The FE Protocol LFB is a logical entity in each FE that is used to 755 control the ForCES protocol. The CE operates on this LFB to 756 subscribe or unsubscribe to Heartbeat messages, define the 757 Heartbeat interval, or to discover which ForCES protocol version 758 is supported and which TMLs the FE supports. The FE Protocol LFB 759 also contains the various ForCES ID to be used: unicast IDs a 760 table of the PL multicast IDs the FE must be listening to. 762 o The FE LFB (referred to as "FE attributes" in the model draft) 763 should not be confused with the FE Protocol Object. The FE LFB is 764 a logical entity in each FE and contains attributes relative to 765 the FE itself, and not to the operation of the ForCES protocol 766 between the CE and the FE. Such attributes can be FEState (refer 767 to model draft), vendor, etc. The FE LFB contains in particular a 768 table that maps a virtual LFB Instance ID to one or more Instance 769 IDs of LFBs in the FE. 771 3.3.3 Scaling by Concurrency 773 It is desirable that the PL layer not become the bottleneck when 774 larger bandwidth pipes become available. To pick a mythical example 775 in today's terms, if a 100Gbps pipe is available and there is 776 sufficient work then the PL layer should be able to take advantage of 777 this and use all of the 100Gbps pipe. Two mechanisms are provided to 778 achieve this. The first one is batching and the second one is a 779 command window. 781 Batching is the ability to send multiple commands (such as Config) in 782 one PDU. The size of the batch will be affected by, amongst other 783 things, the path MTU. The commands may be part of the same 784 transaction or part of unrelated transactions that are independent of 785 each other. 787 Command windowing allows for pipelining of independent transactions 788 which do not affect each other. Each independent transaction could 789 consist of one or more batches. 791 3.3.3.1 Batching 793 There are several batching levels at different protocol hierarchies. 795 o multiple PL PDUs can be aggregated under one TML message 797 o multiple LFB classes and instances can be addressed within one PL 798 PDU 800 o Multiple operations can be addressed to a single LFB class and 801 instance 803 4. TML Requirements 805 The requirements below are expected to be delivered by the TML. This 806 text does not define how such mechanisms are delivered. As an 807 example they could be defined to be delivered via hardware or between 808 2 or more TML processes on different CEs or FEs in protocol level 809 schemes. 811 Each TML must describe how it contributes to achieving the listed 812 ForCES requirements. If for any reason a TML does not provide a 813 service listed below a justification needs to be provided. 815 1. Reliability 816 As defined by RFC 3654, section 6 #6. 818 2. Security 819 TML provides security services to the ForCES PL. TML layer 820 should support the following security services and describe how 821 they are achieved. 823 * Endpoint authentication of FE and CE. 825 * Message Authentication 827 * Confidentiality service 829 3. Congestion Control 830 The congestion control scheme used needs to be defined. 831 Additionally, the circumstances under which notification is sent 832 to the PL to notify it of congestion must be defined. 834 4. Uni/multi/broadcast addressing/delivery if any 835 If there is any mapping between PL and TML level Uni/Multi/ 836 Broadcast addressing it needs to be defined. 838 5. HA decisions 839 It is expected that availability of transport links is the TML's 840 responsibility. However, on config basis, the PL layer may wish 841 to participate in link failover schemes and therefore the TML 842 must support this capability. 843 Please refer to the HA Section Section 8 for details. 845 6. Encapsulations used. 846 Different types of TMLs will encapsulate the PL messages on 847 different types of headers. The TML needs to specify the 848 encapsulation used. 850 7. Prioritization 851 It is expected that the TML will be able to handle up to 8 852 priority levels needed by the PL layer and will provide 853 preferential treatment. 854 TML needs to define how this is achieved. 856 8. The requirement for supporting up to 8 priority levels does not 857 mean that the underlying TML MUST be capable of handling up to 8 858 priority levels. In such an event the priority levels should be 859 divided between the available TML priotity levels. For example, 860 if the TML only support 2 priority levels, the 0-3 could go in 861 one TML priority level, while 4-7 could go in the other. 863 9. Protection against DoS attacks 864 As described in the Requirements RFC 3654, section 6 866 4.1 TML Parameterization 868 It is expected that it should be possible to use a configuration 869 reference point, such as the FEM or the CEM, to configure the TML. 871 Some of the configured parameters may include: 873 o PL ID 875 o Connection Type and associated data. For example if a TML uses 876 IP/TCP/UDP then parameters such as TCP and UDP ports, IP addresses 877 need to be configured. 879 o Number of transport connections 881 o Connection Capability, such as bandwidth, etc. 883 o Allowed/Supported Connection QoS policy (or Congestion Control 884 Policy) 886 5. Message encapsulation 888 All PL layer PDUs start with a common header [Section 5.1] followed 889 by a one or more TLVs [Section 5.2] which may nest other TLVs 890 [Section 5.2.1]. 892 5.1 Common Header 894 0 1 2 3 895 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 896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 897 |version| rsvd | Message Type | Length | 898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 899 | Source ID | 900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 901 | Destination ID | 902 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 903 | Sequence Number | 904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 905 | Correlator | 906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 907 | Flags | 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 910 Figure 6: Common Header 912 The message is 32 bit aligned. 914 Version (4 bit): 915 Version number. Current version is 1. 917 rsvd (4 bit): 918 Unused at this point. A receiver should not interpret this 919 field. Senders SHOULD set it to zero. 921 Message Type (8 bits): 922 Commands are defined in Section 6. 924 Source ID (32 bit): 926 Dest ID (32 bit): 928 * Each of the source and Dest IDs are 32 bit IDs which 929 recognize the termination points. Ideas discussed so far are 930 desire to recognize if ID belongs to FE or CE by inspection. 931 Suggestions for achieving this involves partitioning of the 932 ID allocation. Another alternative maybe to use flags to 933 indicate direction (this avoids partition). 935 * IDs will allow multi/broad/unicast 937 * Addressing 939 a. As ForCES may run between multiple CEs and FEs and over 940 different protocols such as IPv4 and IPv6, or directly 941 over Ethernet or other switching-fabric interconnects, it 942 is necessary to create an addressing scheme for ForCES 943 entities. Mappings to the underlying TML-level 944 addressing can then be defined as appropriate. 946 b. Fundamentally, unique IDs are assigned to CEs and FEs. A 947 split address space is used to distinguish FEs from CEs. 948 Even though we can assume that in a large NE there are 949 typically two or more orders of magnitude more FEs than 950 CEs, the address space is split uniformly for simplicity. 952 c. Special IDs are reserved for FE broadcast, CE broadcast, 953 and NE broadcast. 955 d. Subgroups of FEs belonging, for instance, to the same 956 VPN, may be assigned a multicast ID. Likewise, subgroups 957 of CEs that act, for instance, in a back-up mode may be 958 assigned a multicast ID. These FEs and CE multicast IDs 959 are chosen in a distinct portion of the ID address space. 960 Such a multicast ID may comprise FEs, CEs, or a mix of 961 both. 963 e. As a result, the address space allows up to 2^30 (over a 964 billion) CEs and the same amount of FEs. 966 0 1 2 3 967 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 968 0 1 2 3 969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 970 |TS | sub-ID | 971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 973 Figure 7: ForCES ID Format 975 f. The ForCES ID is 32 bits. The 2 most significant bits 976 called Type Switch (TS) are used to split the ID space as 977 follows: 979 A. TS Corresponding ID range Assignment 980 B. -- ---------------------- ---------- 982 C. 0b00 0x00000000 to 0x3FFFFFFF FE IDs (2^30) 984 D. 0b01 0x40000000 to 0x7FFFFFFF CE IDs (2^30) 986 E. 0b10 0x80000000 to 0xBFFFFFFF reserved 988 F. 0b11 0xC0000000 to 0xFFFFFFEF multicast IDs 989 (2^30 - 16) 991 G. 0b11 0xFFFFFFF0 to 0xFFFFFFFC reserved 993 H. 0b11 0xFFFFFFFD all CEs broadcast 995 I. 0b11 0xFFFFFFFE all FEs broadcast 997 J. 0b11 0xFFFFFFFF all FEs and CEs 998 (NE) broadcast 1000 g. It is desirable to address multicast and/or broadcast 1001 messages to some LFB instances of a given class. For 1002 instance, assume FEs FEa and FEb: 1004 - FEa has LFBs LFBaX1 and LFBaX2 of class X 1006 - similarly, FEb has two LFBs LFBbX1 and LFBbX2 of 1007 class X. 1009 A broadcast message should be addressable to only LFBs 1010 LFBaX1 and LFBbX1 (this can be the case for instance if 1011 these two LFBs belong to the same VPN). To achieve this, 1012 a VPN ID (3 octets OUI and 4 octets VPN Index) as defined 1013 in RFC 2685 should be used within the ForCES message body 1014 as a TLV. 1016 As an alternative, a particular multicast ID MAY be 1017 associated to a given VPN ID through some configuration 1018 means. Messages delivered to such a multicast ID MUST 1019 only be applied to LFBs belonging to that VPN ID. 1021 Sequence (32 bits) 1022 Unique to a PDU. [Discussion: There may be impact on the effect 1023 of subsequence numbers]. 1025 Length (16 bits): 1026 length of header + the rest of the message in DWORDS (4 byte 1027 increments). 1029 Correlator (32 bits) 1030 This field is used to correlate the ForCES Requests messages 1031 (typically sent from CE to FE) with the corresponding Response 1032 messages (typically sent from FE to CE). 1034 Flags(32 bits): 1035 Identified so far: 1037 - ACK indicator(2 bit) 1038 The description for using the two bits is: 1040 'NoACK' (00) 1042 'SuccessACK'(01) 1044 'UnsuccessACK'(10) 1046 'ACKAll' (11) 1048 - Priority (3 bits) 1049 ForCES protocol defines 8 different levels of priority (0-7). 1050 The priority level can be used to distinguish between 1051 different protocol message types as well as between the same 1052 message type. For example, the REDIRECT PACKET message could 1053 have different priorities to distinguish between Routing 1054 protocols packets and ARP packets being redirected from FE to 1055 CE. The Normal priority level is 1. 1057 - Throttle flag 1059 - Batch (2 bits) 1061 - Atomicity (1 or more bits. TBD) 1063 5.2 Type Length Value 1064 0 1 2 3 1065 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 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 | TLV Type | variable TLV Length | 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 | Value (Data of size TLV length) | 1070 ~ ~ 1071 ~ ~ 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 TLV Type: 1076 The TLV type field is two octets, and indicates the type of data 1077 encapsulated within the TLV. 1079 TLV Length: 1081 The TLV Length field is two octets, and indicates the length of 1082 this TLV including the TLV Type, TLV Length, and the TLV data. 1084 TLV Value: 1086 The TLV Value field carries the data. For extensibility, the TLV 1087 Value may be a TLV. In fact, this is the case with the 1088 Netlink2-extension TLV. The Value encapsulated within a TLV is 1089 dependent of the attribute being configured and is opaque to 1090 Netlink2 and therefore is not restricted to any particular type 1091 (example could be ascii strings such as XML, or OIDs etc). 1093 TLVs must be 32 bit aligned. 1095 Figure 8: TLV 1097 5.2.1 Nested TLVs 1099 TLV values can be other TLVs. This provides the benefits of protocol 1100 flexibility (being able to add new extensions by introducing new TLVs 1101 when needed). The nesting feature also allows easy mapping between 1102 the XML LFB definitions to binary PL representation. 1104 5.2.2 Scope of the T in TLV 1106 The "Type" value in TLV is of global scope. This means that wherever 1107 in the PDU hierachy a Type has global connotations. This is a design 1108 choice to ease debugging of the protocol. 1110 6. Protocol Construction 1112 6.1 Protocol Grammar 1114 The protocol construction is formally defined using a BNF-like syntax 1115 to describe the structure of the PDU layout. This is matched to a 1116 precise binary format later in the document. 1118 Since the protocol is very flexible and hierachical in nature, it is 1119 easier at times to see the visualization layout. This is provided in 1120 Section 6.1.2 1122 6.1.1 Protocol BNF 1124 The format used is based on RFC 2234. The terminals of this gramar 1125 are flags, IDcount, IDs, KEYID, KEY_DATA and DATARAW, described after 1126 the grammar. 1128 1. A TLV will have the word "TLV" at the end of its name 1130 2. / is used to separate alternatives 1132 3. parenthesised elements are treated as a single item 1134 4. * before an item indicates 0 or more repetitions 1* before an 1135 item indicates 1 or more repetitions 1137 5. [] around an item indicates that it is optional (equal to *1) 1139 The BNF of the PL level PDU is as follows: 1141 PL level PDU := MAINHDR 1*LFBselect-TLV 1142 LFBselec-TLV := LFBCLASSID LFBInstance 1*OPER-TLV 1143 OPER-TLV := 1*PATH-DATA-TLV 1144 PATH-DATA-TLV := PATH [DATA] 1145 PATH := flags IDcount IDs [SELECTOR] 1146 SELECTOR := KEYINFO-TLV 1147 DATA := DATARAW-TLV / RESULT-TLV / 1*PATH-DATA-TLV 1148 KEYINFO-TLV := KEYID KEY_DATA 1149 DATARAW-TLV := encoded data which may nest DATARAW TLVs 1150 RESULT-TLV := Holds result code and optional DATARAW 1152 o MAINHDR defines a message type, Target FE/CE ID etc. The MAINHDR 1153 also defines the content. As an example the content of a "config" 1154 message would be different from an "association" message. 1156 o LFBCLASSID is a 32 bit unique identifier per LFB class defined at 1157 class Definition time. 1159 o LFBInstance is a 32 bit unique instance identifier of an LFB class 1161 o OPERATION is one of {ADD,DEL,etc.} depending on the message type 1163 o PATH-DATA-TLV identifies the exact element targeted. It may have 1164 zero or more paths associated with it terminated by zero or more 1165 data values associated. 1167 o PATH provides the path to the data being referenced. 1169 * flags (16 bits) are used to further refine the operation to be 1170 applied on the Path. More on these later. 1172 * IDcount(16 bit): count of 32 bit IDs 1174 * IDs: zero or more 32bit IDs (whose count is given by IDcount) 1175 defining the main path. Depending on the flags, IDs could be 1176 field IDs only or a mix of field and dynamic IDs. Zero is used 1177 for the special case of using the entirety of the containing 1178 context as the result of the path. 1180 o SELECTOR is an optional construct that further defines the PATH. 1181 Currently, the only defined selector is the KEYINFO-TLV, used for 1182 selecting an array entry by the value of a key field. The 1183 presence of a SELECTOR is correct only when the flags also 1184 indicate its presence. A mismatch is a protocol format error. 1186 o A KEYINFO TLV contains information used in content keying. 1188 * A KeyID is used in a KEYINFO TLV. It indicates which key for 1189 the current array is being used as the content key for array 1190 entry selection. 1192 * KEY_DATA is the data to look for in the array, in the fields 1193 identified by the keyfield. The information is encoded 1194 according to the rules for the contents of a DATARAW, and 1195 represent the field or fields which make up the key identified 1196 by the KEYID. 1198 o DATA may contain a DATARAW or 1 or more further PATH-DATA 1199 selection DATARAW is only allowed on SET requests, or on responses 1200 which return content information (GET Response for example.) 1201 PATH-DATA may be included to extent the path on any request. 1203 * Note: Nested PATH-DATA TLVs are supported as an efficiency 1204 measure to permit common subexpression extraction. 1206 * DATARAW contains "the data" whose path is selected. 1208 o RESULT contains the indication of whether the individual SET 1209 succeeded. If there is an indication for verbose response, then 1210 SETRESULT will also contain the DATARAW showing the data that was 1211 set. RESULT-TLV is included on the assumption that individual 1212 parts of a SET request can succeed or fail separately. 1214 In summary this approach has the following characteristic: 1216 o There can be one or more LFB Class + InstanceId combo targeted in 1217 a message (batch) 1219 o There can one or more operations on an addressed LFB classid+ 1220 instanceid combo(batch) 1222 o There can be one or more path targets per operation (batch) 1224 o Paths may have zero or more data values associated (flexibility 1225 and operation specific) 1227 It should be noted that the above is optimized for the case of a 1228 single classid+instance targeting. To target multiple instances 1229 within the same class, multiple LFBselect are needed. 1231 6.1.1.1 Discussion on Grammar 1233 Data is packed in such a way that a receiver of such data with 1234 knowledge of the path can correlate what it means by infering in the 1235 LFB definition. This is an optimization that helps reducing the 1236 amount of description for the data in the protocol. 1238 In other words: 1240 It is assumed that the type of the data can be inferred by the 1241 context in which data is used. Hence, data will not include its type 1242 information. The basis for the inference is typically the LFB class 1243 id and the path. 1245 6.1.1.1.1 Data Packing Rules 1247 The scheme for packaging data used in this doc adheres to the 1248 following rules: 1250 o The Value of DATARAW TLV will contain the data being transported. 1251 This data will be as was described in the LFB definition. 1253 o By definition in the Forces protocol, all TLVs are 32 bit aligned. 1254 Therefore because DATARAW is a TLV, elements not aligned in 32 bit 1255 values will be padded. 1257 * As an example a 16 bit value will have an extra 16 bit pad; 1258 however two 16 bits values in a structure will be shipped 1259 together with no padding etc. 1261 o Variable sized data will be encapsulated inside another DATARAW 1262 TLV inside the V of the outer TLV. For example of this see 1263 Appendix D example 13. 1265 o When a table is refered in the PATH (ids), then the RAWDATA's V 1266 will contain that tables row content prefixed by its 32 bit index/ 1267 subscript OTOH, when PATH flags are 00, the PATH may contain an 1268 index pointing to a row in table; in such a case, the RAWDATA's V 1269 will only contain the content with the index in order to avoid 1270 ambiguity. 1272 6.1.1.1.2 Path Flags 1274 The following flags are currently defined: 1276 o SELECTOR Bit: F_SELKEY indicates that a KEY Selector is present 1277 following this path information, and should be considered in 1278 evaluating the path. 1280 o FIND-EMPTY Bit: This must not be set if the F_SEL_KEY bit is set. 1281 This must only be used on a create operation. If set, this 1282 indicates that although the path identifies an array, the SET 1283 operation should be applied to the first unused element in the 1284 array. The result of the operation will not have this flag set, 1285 and will have the assigned index in the path. 1287 6.1.1.1.3 Relation of operational flags with global message flags 1289 Should be noted that other applicable flags such as atomicity 1290 indicators as well as verbosity result formaters are in the main 1291 headers flags area. 1293 6.1.1.1.4 Content Path Selection 1295 The KEYINFO TLV describes the KEY as well as associated KEY data. 1297 KEYs, used for content searches, are restricted and described in the 1298 LFB definition. 1300 6.1.1.1.5 Operation TLVs 1302 It is assumed that specific operations are identified by the type 1303 code of the TLV. And that response are also identified by specific 1304 TLV opcodes 1306 6.1.1.1.6 SET and GET Relationship 1308 It is expected that a GET-RESPONSE would satisfy the following 1309 desires: 1311 o it would have exactly the same path definitions as that was sent 1312 in the GET. The only difference being a GET-RESPONSE will contain 1313 DATARAW TLVs. 1315 o it should be possible that one would take the same GET-RESPONSE 1316 and convert it to a SET-REPLACE successfully by merely changing 1317 the T in the operational TLV. 1319 o There are exceptions to this rule: 1321 1. When a KEY selector is used with a path in a GET operation, 1322 that selector is not returned in the GET-RESPONSE; instead the 1323 cooked result is returned. Refer to the examples using KEYS 1324 to see this. 1326 2. When dumping a whole table in a GET, the GET-RESPONSE, merely 1327 editing the T to be SET will endup overwritting the table. 1329 6.1.2 Protocol Visualization 1331 The figure below shows a general layout of the PL PDU. A main header 1332 is followed by one or more LFB selections each of which may contain 1333 one or more operation. 1335 main hdr (Config in this case) 1336 | 1337 | 1338 +--- T = LFBselect 1339 | | 1340 | +-- LFBCLASSID 1341 | | 1342 | | 1343 | +-- LFBInstance 1344 | | 1345 | +-- T = SET-CREATE 1346 | | | 1347 | | +-- // one or more path targets 1348 | | // with their data here to be added 1349 | | 1350 | +-- T = DEL 1351 | . | 1352 | . +-- // one or more path targets to be deleted 1353 | 1354 | 1355 +--- T = LFBselect 1356 | | 1357 | +-- LFBCLASSID 1358 | | 1359 | | 1360 | +-- LFBInstance 1361 | | 1362 | + -- T= SET-REPLACE 1363 | | 1364 | | 1365 | + -- T= DEL 1366 | | 1367 | + -- T= SET-REPLACE 1368 | 1369 | 1370 +--- T = LFBselect 1371 | 1372 +-- LFBCLASSID 1373 | 1374 +-- LFBInstance 1375 . 1376 . 1377 . 1379 Figure 10: PL PDU layout 1381 The figure below shows an example general layout of the operation 1382 within a targetted LFB selection. The idea is to show the different 1383 nesting levels a path could take to get to the target path. 1385 T = SET-CREATE 1386 | | 1387 | +- T = Path-data 1388 | | 1389 | + -- flags 1390 | + -- IDCount 1391 | + -- IDs 1392 | | 1393 | +- T = Path-data 1394 | | 1395 | + -- flags 1396 | + -- IDCount 1397 | + -- IDs 1398 | | 1399 | +- T = Path-data 1400 | | 1401 | + -- flags 1402 | + -- IDCount 1403 | + -- IDs 1404 | + -- T = KEYINFO 1405 | | + -- KEY_ID 1406 | | + -- KEY_DATA 1407 | | 1408 | + -- T = DATARAW 1409 | + -- data 1410 | 1411 | 1412 T = SET-REPLACE 1413 | | 1414 | +- T = Path-data 1415 | | | 1416 | | + -- flags 1417 | | + -- IDCount 1418 | | + -- IDs 1419 | | | 1420 | | + -- T = DATARAW 1421 | | + -- data 1422 | +- T = Path-data 1423 | | 1424 | + -- flags 1425 | + -- IDCount 1426 | + -- IDs 1427 | | 1428 | + -- T = DATARAW 1429 | + -- data 1430 T = DEL 1431 | 1432 +- T = Path-data 1433 | 1434 + -- flags 1435 + -- IDCount 1436 + -- IDs 1437 | 1438 +- T = Path-data 1439 | 1440 + -- flags 1441 + -- IDCount 1442 + -- IDs 1443 | 1444 +- T = Path-data 1445 | 1446 + -- flags 1447 + -- IDCount 1448 + -- IDs 1449 + -- T = KEYINFO 1450 | + -- KEY_ID 1451 | + -- KEY_DATA 1452 +- T = Path-data 1453 | 1454 + -- flags 1455 + -- IDCount 1456 + -- IDs 1458 Figure 11: Sample operation layout 1460 6.2 Core ForCES LFBs 1462 There are three LFBs that are used to control the operation of the 1463 ForCES protocol and to interact with FEs and CEs: 1465 FE protocol LFB 1467 FE LFB 1469 Although these LFBs have the same form and interface as other LFBs, 1470 they are special in many respects: they have fixed well-known LFB 1471 Class and Instance IDs. They are statically defined (no dynamic 1472 instantiation allowed) and their status cannot be changed by the 1473 protocol: any operation to change the state of such LFBs (for 1474 instance, in order to disable the LFB) must result in an error. 1475 Moreover, these LFBs must exist before the first ForCES message can 1476 be sent or received. All attributes in these LFBs must have pre- 1477 defined default values. Finally, these LFBs do not have input or 1478 output ports and do not integrate into the intra-FE LFB topology. 1480 6.2.1 FE Protocol LFB 1482 The FE Protocol LFB is a logical entity in each FE that is used to 1483 control the ForCES protocol. The FE Protocol LFB Class ID is 1484 assigned the value 0x1. The FE LFB Instance ID is assigned the value 1485 0x1. There MAY be one and only one instance of the FE Protocol LFB 1486 in an FE. The values of the attributes in the FE Protocol LFB have 1487 pre-defined default values that are specified here. Unless explicit 1488 changes are made to these values using Config messages from the CE, 1489 these default values MUST be used for the operation of the protocol. 1491 The formal definition of the FE Protocol LFB can be found in 1492 Appendix C 1494 The FE Protocol LFB consists of the following elements: 1496 o FE Protocol events that can be subscribed/unsubscribed: 1498 * FE heartbeat 1500 o FE Protocol capabilities (read-only): 1502 * Supported ForCES protocol version(s) by the FE 1504 * Supported ForCES FE model(s) by the FE 1506 * Some TML capability description(s) 1508 o FE Protocol attributes (can be read and set): 1510 * Current version of the ForCES protocol 1512 * Current version of the FE model 1514 * FE unicast ID 1516 * FE multicast ID(s) (list) 1518 * Association Expiry Timer. Defualt Value = 900 msec 1519 * Heartbeat Interval. Defualt Value = 300 msec 1521 * Primary CE 1523 * FE failover and restart policy - This specifies the behavior of 1524 the FE during a CE failure and restart time interval. For 1525 example, this would specify if the FE should continue running 1526 or stop operation during a CE failure in the NE. 1528 * CE failover and restart policy - - This specifies the behavior 1529 of the CE during a FE failure and restart time interval. For 1530 example, this would specify if the CE should continue running 1531 or stop operation during a FE failure in the NE. 1533 6.2.2 FE Object LFB 1535 The FE Object LFB is a logical entity in each FE and contains 1536 attributes relative to the FE itself, and not to the operation of the 1537 ForCES protocol. The FE LFB Class ID is assigned the value 0x2. The 1538 FE LFB Instance ID is assigned the value 0x1. There must always be 1539 one and only one instance of the FE LFB in an FE. 1541 The formal definition of the FE Object LFB can be found in [FE-MODEL] 1543 The FE LFB consists of the following elements: 1545 FE Events: 1547 * FEAllEvents: subscribing to this corresponds to subscribing to 1548 all events below 1550 * FEStatusChange: events that signal FE Status: 1552 + Up 1554 + Down 1556 + Active 1558 + Inactive 1560 + Failover 1562 * FE DoS alert 1564 * FE capability change 1565 FE attributes: 1567 * FEStatus: to set the FE mode as: 1569 + Active 1571 + Inactive 1573 + Shutdown 1575 * FELFBInstancelist 1577 * FENeighborList 1579 * MIID table: a list of virtual LFB Instance IDs that map to a 1580 list of Instance IDs of LFBs in that FE 1582 * FE Behavior Exp. Timer 1584 * HA Mode 1586 * FE DoS protection policy 1588 * FEPrivateData: Proprietary info such as name, vendor, model. 1590 * Inter-FE topology Intra-FE topology 1592 6.3 Semantics of message Direction 1594 Recall: The PL protocol provides a master(CE)-Slave(FE) relationship. 1595 The LFBs reside at the FE and are controlled by CE. 1597 When messages go from the CE, the LFB Selector (Class and instance) 1598 refers to the destination LFB selection which resides in the FE. 1600 When messages go from the FE->CE, the LFB Selector (Class and 1601 instance) refers to the source LFB selection which resides in the FE. 1603 6.4 Association Messages 1605 The ForCES Association messages are used to establish and teardown 1606 associations between FEs and CEs. 1608 6.4.1 Association Setup Message 1610 This message is sent by the FE to the CE to setup a ForCES 1611 association between them. This message could also be used by CEs to 1612 join a ForCES NE, however CE-to-CE communication is not covered by 1613 this protocol. 1615 Message transfer direction: 1616 FE to CE 1618 Message Header: 1619 The Message Type in the header is set MessageType= 'Association 1620 Setup'. The ACK flag in the header is ignored, because the setup 1621 message will always expect to get a response from the message 1622 receiver (CE) whether the setup is successful or not. The Src ID 1623 (FE ID) may be set to O in the header which means that the FE 1624 would like the CE to assign a FE ID for the FE in the setup 1625 response message. 1627 Message body: 1628 The LFB selection may point to the FE Object and/or FE Protocol 1629 LFBs and more than one attribute may be announced in this message 1630 using GET-REPONSE to let the FE declare its configuration 1631 parameters in an unsolicited manner. The layout is: 1633 main hdr (eg type = Association setup) 1634 | 1635 | 1636 +--- T = LFBselect 1637 | | 1638 | +-- LFBCLASSID = FE object 1639 | | 1640 | | 1641 | +-- LFBInstance = 0x1 1642 | | 1643 +--- T = LFBselect 1644 | 1645 +-- LFBCLASSID = FE Protocol object 1646 | 1647 | 1648 +-- LFBInstance = 0x1 1649 | 1650 +-- Path-data to one or more attibutes 1651 including suggested HB parameters 1653 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 1655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1656 | Type = LFB select | Length | 1657 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1658 | LFB Class ID = FE Object | 1659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1660 | LFB Instance ID | 1661 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1662 | | 1663 ~ Attributes path and data ~ 1664 ~ ~ 1665 ~ ~ 1666 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1667 | Type = LFB select | Length | 1668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1669 | LFB Class ID = FE Protocol Object | 1670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1671 | LFB Instance ID | 1672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1673 | | 1674 ~ ~ 1675 ~ Attributes path and data ~ 1676 ~ ~ 1677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1678 Figure 12 1680 Type (16 bits): 1681 LFB Select 1683 Length (16 bits): 1684 Length of the TLV including the T and L fields, in bytes. 1686 FE Object and Protocol LFBs: 1687 These contains the FE parameters e.g. HBI may be exchanged with 1688 the CE using the FE Protocol LFB. 1690 6.4.2 Association Setup Response Message 1692 This message is sent by the CE to the FE in response to the Setup 1693 message. It indicates to the FE whether the setup is successful or 1694 not, i.e. whether an association is established. 1696 Message transfer direction: 1697 CE to FE 1699 Message Header: 1700 The Message Type in the header is set MessageType= 'Setup 1701 Response'. The ACK flag in the header is always ignored, because 1702 the setup response message will never expect to get any more 1703 response from the message receiver (FE). The Dst ID in the 1704 header will be set to some FE ID value assigned by the CE if the 1705 FE had requested that in the setup message (by SrcID = 0). 1707 Message body: 1708 The LFB selection may point to the FE Object and/or FE Protocol 1709 LFBs and more than one attribute may be announced in this 1710 message. The layout is: 1712 main hdr (eg type = Association setup response) 1713 | 1714 | 1715 | 1716 +--- T = LFBselect 1717 | | 1718 | +-- LFBCLASSID = FE object 1719 | | 1720 | | 1721 | +-- LFBInstance = 0x1 1722 | | 1723 | +--- T = Operation = SET 1724 | | 1725 | +-- Path-data to one or more attibutes 1726 | including FE NAME 1727 | 1728 +--- T = LFBselect 1729 | 1730 +-- LFBCLASSID = FE Protocol object 1731 | 1732 | 1733 +-- LFBInstance = 0x1 1734 | 1735 +--- T = Operation = SET 1736 | 1737 +-- Path-data to one or more attibutes 1738 eg HB parameters 1740 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 1742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1743 | Type = LFB select | Length | 1744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1745 | LFB Class ID = FE Object | 1746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1747 | LFB Instance ID | 1748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1749 | Type = operation SET | Length | 1750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1751 | | 1752 ~ Attributes path and data ~ 1753 ~ ~ 1754 ~ ~ 1755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1756 | Type = LFB select | Length | 1757 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1758 | LFB Class ID = FE Protocol Object | 1759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1760 | LFB Instance ID | 1761 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1762 | Type = operation SET | Length | 1763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1764 | | 1765 ~ ~ 1766 ~ Attributes path and data ~ 1767 ~ ~ 1768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1769 Figure 13 1771 Type (16 bits): 1772 LFB Select 1774 Length (16 bits): 1775 Length of the TLV including the T and L fields, in bytes. 1777 FE Object LFB: 1778 The FE parameters e.g. HBI may be exchanged using this LFB. 1780 Result (16 bits): 1781 This indicates whether the setup msg was successful or whether 1782 the FE request was rejected by the CE. the defined values are: 1784 0 = success 1786 1 = FE ID invalid 1788 2 = too many associations 1790 3 = permission denied 1792 6.4.3 Association Teardown Message 1794 This message can be sent by the FE or CE to any ForCES element to end 1795 its ForCES association with that element. 1797 Message transfer direction: 1798 CE to FE, or FE to CE (or CE to CE) 1800 Message Header: 1801 The Message Type in the header is set MessageType= "Asso. 1802 Teardown". The ACK flag in the header is always ignored, because 1803 the teardown message will never expect to get any response from 1804 the message receiver. 1806 Message Body: 1807 The association teardown message body consists of LFBSelect & 1808 FEReason TLV, the format of which is as follows: 1810 main hdr (eg type = Association tear) 1811 | 1812 | 1813 | 1814 +--- T = Teardown Reason 1815 | 1816 +-- Teardown Reason code 1818 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 1819 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1820 | Type = Teardown reason | Length | 1821 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1822 | Teardown Reason | 1823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1825 Figure 14 1827 Type (16 bits): 1828 LFB Select 1830 Length (16 bits): 1831 Length of the TLV including the T and L fields, in bytes. 1833 Teardonw Reason (32 bits): 1834 This indicates the reason why the association is being 1835 terminated. Several reason codes are defined as follows. 1837 0 - normal teardown by administrator 1839 1 - error - out of memory 1841 2 - error - application crash 1843 255 - error - other or unspecified 1845 6.5 Configuration Messages 1847 The ForCES Configuration messages are used by the CEs to configure 1848 the FEs in a ForCES NE and report the results back to the CE. 1850 6.5.1 Config Message 1852 This message is sent by the CE to the FE to configure FE or LFB 1853 attributes. This message is also used by the CE to subscribe/ 1854 unsubscribe to FE and LFB events. 1856 Message transfer direction: 1857 CE to FE 1859 Message Header: 1860 The Message Type in the header is set MessageType= 'Config'. The 1861 ACK flag in the header is can be used by the CE to turn off any 1862 response from the FE. The default behavior is to turn on the ACK 1863 to get the config response from the FE. 1865 Message body: 1866 The Config message body consists of one or more TLVs, the format 1867 of a single (LFB) TLV is as follows: 1869 main hdr (eg type = config) 1870 | 1871 | 1872 +--- T = LFBselect 1873 | | 1874 | +-- LFBCLASSID = target LFB class 1875 | | 1876 | | 1877 | +-- LFBInstance = target LFB instance 1878 | | 1879 | | 1880 | +-- T = operation { SET, DEL } 1881 | | | 1882 | | +-- // one or more path targets 1883 | | // discussed later 1884 | | 1885 | +-- T = operation { SET, DEL } 1886 | | | 1887 | | +-- // one or more path targets 1888 | | // discussed later 1889 | | 1890 | +-- T = operation { SET, DEL } 1891 | | | 1892 | | +-- // one or more path targets 1893 | | // discussed later 1894 | | 1896 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 1897 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1898 | Type = LFB select | Length | 1899 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1900 | LFB Class ID | 1901 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1902 | LFB Instance ID | 1903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1904 | Operation (SET) | Length | 1905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1906 | | 1907 ~ Config path ~ 1908 | | 1909 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1910 | Operations (DEL) | Length | 1911 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1912 | | 1913 ~ Config path ~ 1914 | | 1915 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1916 Figure 15 1918 Type (16 bits): 1919 LFB Select. 1921 Length (16 bits): 1922 Length of the TLV including the T and L fields, in bytes. 1924 LFB Class ID (16 bits): 1925 This field uniquely recognizes the LFB class/type. 1927 LFB Instance ID (16 bits): 1928 This field uniquely identifies the LFB instance. 1930 Type (16 bits): 1931 The operations include, ADD, DEL, UPDATE/REPLACE, DEL ALL, EVENT 1932 SUBSCRIBE, EVENT UNSUBSCRIBE, CANCEL. 1934 Length (16 bits): 1935 Length of the TLV including the T and L fields, in bytes. 1937 Config path + Data (variable length): 1938 This will carry LFB specific data The config data will be in the 1939 form of a TLV. Should be noted only a CREATE, REPLACE will have 1940 data while the rest will only carry path information of what to 1941 DELete or GET. 1943 *Note: FE Activate/Deactivate, Shutdown FE commands for State 1944 Maintenance will be sent using Config messages. 1946 *Note: For Event subscription, the events will be defines by the 1947 individual LFBs. 1949 6.5.2 Config Response Message 1951 This message is sent by the FE to the CE in response to the Config 1952 message. It indicates whether the Config was successful or not on 1953 the FE and also gives a detailed response regarding the configuration 1954 result of each attribute. 1956 Message transfer direction: 1957 FE to CE 1959 Message Header: 1960 The Message Type in the header is set MessageType= 'Config 1961 Response'. The ACK flag in the header is always ignored, because 1962 the config response message will never expect to get any more 1963 response from the message receiver (CE). 1965 Message body: 1966 The Config response message body consists of one or more TLVs, 1967 the format of a single TLV is as follows: 1969 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 1971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1972 | Type = LFB select | Length | 1973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1974 | LFB Class ID | 1975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1976 | LFB Instance ID | 1977 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1978 | Operation Result | reserved | 1979 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1980 | Path-data TLV | 1981 | | 1982 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1983 | Result TLV | 1984 | | 1985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1986 | Operations (DEL-RESP) | Length | 1987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1988 | Path-data TLV | 1989 | | 1990 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1991 | Result TLV | 1992 | | 1993 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1995 Figure 16 1997 Type (16 bits): 1998 LFB Select. 2000 Length (16 bits): 2001 Length of the TLV including the T and L fields, in bytes. 2003 LFB Class ID (16 bits): 2004 This field uniquely recognizes the LFB class/type. 2006 LFB Instance ID (16 bits): 2007 This field uniquely identifies the LFB instance. 2009 Type (16 bits): 2010 The operations are same as those defined for Config messages. 2012 Length (16 bits): 2013 Length of the TLV including the T and L fields, in bytes. 2015 Operation Result (16 bits): 2016 This indicates the overall result of the config operation, 2017 whether it was successful or it failed. 2019 0 = success 2021 1 = FE ID invalid 2023 3 = permission denied 2025 Path-data TLV 2027 Result TLV 2029 6.6 Query and Query Response Messages 2031 The ForCES query and query response messages are used by ForCES 2032 elements (CE or FE) to query LFBs in other ForCES element(s) Current 2033 version of ForCES protocol limits the use of the messages only for CE 2034 to query information of FE. 2036 6.6.1 Query Message 2038 As usual, a query message is composed of a common header and a 2039 message body that consists of one or more TLV data format. Detailed 2040 description of the message is as below. 2042 Message transfer direction: 2043 Current version limits the query message transfer direction only 2044 from CE to FE. 2046 Message Header: 2047 The Message Type in the header is set to MessageType= 'Query'. 2048 The ACK flag in the header SHOULD be set 'ACKAll', meaning a full 2049 response for a query message is always expected. If the ACK flag 2050 is set other values, the meaning of the flag will then be 2051 ignored, and a full response will still be returned by message 2052 receiver. 2054 Message body: 2055 The query message body consists of (at least) one or more than 2056 one TLVs that describe entries to be queried. The TLV is called 2057 LFBselect TLV and the data format is as below: 2059 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 2060 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2061 | Type = LFBselect | Length | 2062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2063 | LFB Class ID | 2064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2065 | LFB Instance ID | 2066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2067 | Operation TLV | 2068 . . 2069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2070 ~ ... ~ 2071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2072 | Operation TLV | 2073 . . 2074 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2076 Figure 17 2078 Operation TLV: 2079 The Operation TLV for the 'Query' message is formatted as: 2081 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2082 | Type = GET | Length | 2083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2084 | PATH-DATA for GET | 2085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2087 Figure 18 2089 PATH-DATA for GET: 2090 This is generically a PATH-DATA format that has been defined in 2091 "Protocol Grammar" section in the PATH-DATA BNF definition, with 2092 the limitation specifically for GET operation that the PATH-DATA 2093 here will not allow DATARAW-TLV and RESULT-TLV present in the 2094 data format, so as to meet the genius of a GET operation. 2096 To better understand the above PDU format, we can show a tree 2097 structure for the format as below: 2099 main hdr (type = Query) 2100 | 2101 | 2102 +--- T = LFBselect 2103 | | 2104 | +-- LFBCLASSID = target LFB class 2105 | | 2106 | | 2107 | +-- LFBInstance = target LFB instance 2108 | | 2109 | | 2110 | +-- T = operation { GET } 2111 | | | 2112 | | +-- // one or more path targets 2113 | | // under discussion 2114 | +-- T = operation { GET } 2115 | | | 2116 | | +-- // one or more path targets 2117 | | 2119 Figure 19 2121 6.6.2 Query Response Message 2123 When receiving a query message, the receiver should process the 2124 message and come up with a query result. The receiver sends the 2125 query result back to the message sender by use of the Query Response 2126 Message. The query result can be the information being queried if 2127 the query operation is successful, or can also be error codes if the 2128 query operation fails, indicating the reasons for the failure. 2130 A query response message is also composed of a common header and a 2131 message body consists of one or more TLVs describing the query 2132 result. Detailed description of the message is as below. 2134 Message transfer direction: 2135 Current version limits the query response message transfer 2136 direction only from FE to CE. 2138 Message Header: 2139 The Message Type in the header is set to MessageType= 2140 'QueryResponse'. The ACK flag in the header SHOULD be set 2141 'NoACK', meaning no further response for a query response message 2142 is expected. If the ACK flag is set other values, the meaning of 2143 the flag will then be ignored. The Sequence Number in the header 2144 SHOULD keep the same as that of the query message to be 2145 responded, so that the query message sender can keep track of the 2146 responses. 2148 Message body: 2149 The message body for a query response message consists of (at 2150 least) one or more than one TLVs that describe query results for 2151 individual queried entries. The TLV is also called LFBselect 2152 TLV, and has exactly the same data format as query message, 2153 except the Operation TLV content is different. The order of the 2154 TLV here matches the TLVs in the corresponding Query message, and 2155 the TLV numbers should also keep the same. The Operation TLV 2156 here is a 'GET-RESPONSE' TLV and the data is a 'PATH-DATA' 2157 format for Query Response Data, as below: 2159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2160 | Type = GET-RESPOSE | Length | 2161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2162 | PATH-DATA for GET-RESPONSE | 2163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2165 Figure 20 2167 PATH-DATA for GET-RESPONSE: 2168 This is generically a PATH-DATA format that has been defined in 2169 "Protocol Grammar" section in the PATH-DATA BNF definition. The 2170 response data will be included in the DATARAW-TLV and/or RESULT- 2171 TLV inside the PATH-DATA format. 2173 6.7 Event Notification and Response Messages 2175 The Event Notification Message is used to allow one ForCES element to 2176 asynchronously notify one or more other ForCES elements in the same 2177 ForCES NE on events occuring in that ForCES element. The Event 2178 Notification Response Message is used for the receiver of the Event 2179 Notification Message to acknowledge the reception of the event 2180 notification. 2182 Events in current ForCES protocol can be categorized into following 2183 types: 2185 o Events happened in CE 2187 o Events happened in FE 2189 Events can also be categorized into two classes according to whether 2190 they need subscription or not. An event in one ForCES element that 2191 needs to be subscribed will send notifications to other ForCES 2192 elements only when the other elements have subscribed to the element 2193 for the event notification. How to subscribe/unsubscribe for an 2194 event is described in the Configure Message section. An event that 2195 does not need to be subscribed will always send notifications to 2196 other ForCES elements when the event happens. Events will be defined 2197 in the ForCES FE model XML definitions for LFBs as attributes; i.e 2198 they will have a path to them that can be used by the config message 2199 to subscribe to. 2201 6.7.1 Event Notification Message 2203 As usual, an Event Notification Message is composed of a common 2204 header and a message body that consists of one or more TLV data 2205 format. Detailed description of the message is as below. 2207 Message Transfer Direction: 2208 FE to CE, or CE to FE 2210 Message Header: 2211 The Message Type in the message header is set to 2212 MessageType = 'EventNotification'. The ACK flag in the header can 2213 be set as: ACK flag ='NoACK'|'SuccessAck'|'UnsuccessACK'|'ACKAll'. 2214 Note that the 'Success' here only means the receiver of the 2215 message has successfully received the message. 2217 Message Body: 2218 The message body for an event notification message consists of (at 2219 least) one or more than one TLVs that describe the notified 2220 events. The TLV is defined as follows: 2222 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 2223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2224 | Type = LFBselect | Length | 2225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2226 | LFB Class ID | 2227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2228 | LFB Instance ID | 2229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2230 | Operation TLV | 2231 . . 2232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2233 ~ ... ~ 2234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2235 | Operation TLV | 2236 . . 2237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2239 Figure 21 2241 Operation TLV: 2242 This is a TLV that describes the event to be notified, as follows: 2244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2245 | OPER = REPORT | Length | 2246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2247 | PATH-DATA for REPORT | 2248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2250 Figure 22 2252 PATH-DATA for REPORT: 2253 This is generically a PATH-DATA format that has been defined in 2254 "Protocol Grammar" section in the PATH-DATA BNF definition. The 2255 report data will be included in the DATARAW-TLV inside the PATH- 2256 DATA format. 2258 To better understand the above PDU format, we can show a tree 2259 structure for the format as below: 2261 main hdr (type = Event Notification) 2262 | 2263 | 2264 +--- T = LFBselect 2265 | | 2266 | +-- LFBCLASSID = target LFB class 2267 | | 2268 | | 2269 | +-- LFBInstance = target LFB instance 2270 | | 2271 | | 2272 | +-- T = operation { REPORT } 2273 | | | 2274 | | +-- // one or more path targets 2275 | | // under discussion 2276 | +-- T = operation { REPORT } 2277 | | | 2278 | | +-- // one or more path targets 2279 | | 2281 Figure 23 2283 6.7.2 Event Notification Response Message 2285 After sending out an Event Notification Message, the sender may be 2286 interested in ensuring that the message has been received by 2287 receivers, especially when the sender thinks the event notification 2288 is vital for system management. An Event Notification Response 2289 Message is used for this purpose. The ACK flag in the Event 2290 Notification Message header are used to signal if such acknowledge is 2291 requested or not by the sender. 2293 Detailed description of the message is as below: 2295 Message Transfer Direction: 2296 From FE to CE or from CE to FE, just inverse to the direction of 2297 the Event Notification Message that it responses. 2299 Message Header: 2300 The Message Type in the header is set MessageType= 2301 'EventNotificationResponse'. The ACK flag in the header SHOULD be 2302 set 'NoACK', meaning no further response for the message is 2303 expected. If the ACK flag is set other values, the meaning of the 2304 flag will then be ignored. The Sequence Number in the header 2305 SHOULD keep the same as that of the message to be responded, so 2306 that the event notificatin message sender can keep track of the 2307 responses. 2309 Message Body: 2310 The message body for an event notification response message 2311 consists of (at least) one or more than one TLVs that describe the 2312 notified events. The TLV is also called LFBselect TLV, and has 2313 exactly the same data format as Event Notification Message, except 2314 the Operation TLV inside is different. The order of the TLV here 2315 matches the TLVs in the corresponding Event Message, and the TLV 2316 numbers should keep the same. The Operation TLV here is a 2317 'REPORT-RESPONSE' TLV and the data is a 'PATH-DATA' format for 2318 event response data, as below: 2320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2321 | Type = REPORT-RESPONSE | Length | 2322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2323 | PATH-DATA for REPORT-RESPONSE | 2324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2326 Figure 24 2328 PATH-DATA for REPORT-RESPONSE: 2329 This is generically a PATH-DATA format that has been defined in 2330 "Protocol Grammar" section in the PATH-DATA BNF definition. The 2331 response data will be included in the RESULT-TLV inside the PATH- 2332 DATA format. 2334 6.8 Packet Redirect Message 2336 Packet redirect message is used to transfer data packets between CE 2337 and FE. Usually these data packets are IP packets, though they may 2338 sometimes associated with some metadata generated by other LFBs in 2339 the model, or they may occasionally be other protocol packets, which 2340 usually happen when CE and FE are jointly implementing some high- 2341 touch operations. Packets redirected from FE to CE are the data 2342 packets that come from forwarding plane, and usually are the data 2343 packets that need high-touch operations in CE,or packets for which 2344 the IP destination address is the NE. Packets redirected from CE to 2345 FE are the data packets that come from the CE and are decided by CE 2346 to put into forwarding plane in FE. 2348 Supplying such a redirect path between CE and FE actually leads to a 2349 possibility of this path being DoS attacked. Attackers may 2350 maliciously try to send huge spurious packets that will be redirected 2351 by FE to CE, making the redirect path been congested. ForCES 2352 protocol and the TML layer will jointly supply approaches to prevent 2353 such DoS attack. To define a specific 'Packet Redirect Message' 2354 makes TML and CE able to distinguish the redirect messages from other 2355 ForCES protocol messages. 2357 By properly configuring related LFBs in FE, a packet can also be 2358 mirrored to CE instead of purely redirected to CE, i.e., the packet 2359 is duplicated and one is redirected to CE and the other continues its 2360 way in the LFB topology. 2362 The Packet Redirect Message data format is formated as follows: 2364 Message Direction: 2365 CE to FE or FE to CE 2367 Message Header: 2368 The Message Type in the header is set to MessageType= 2369 'PacketRedirect'. The ACK flags in the header SHOULD be set 2370 'NoACK', meaning no response is expected by this message. If the 2371 ACK flag is set other values, the meanings will be ignored. 2373 Message Body: 2374 Consists of one or more TLVs, with every TLV having the following 2375 data format: 2377 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 2378 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2379 | Type = Redirect | Length | 2380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2381 | LFB Class ID | 2382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2383 | LFB Instance ID | 2384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2385 | Meta Data TLV | 2386 . . 2387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2388 | Redirect Data TLV | 2389 . . 2390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2392 Figure 25 2394 LFB class ID: 2395 There are only two possible LFB classes here, the 'RedirectSink' 2396 LFB or the 'RedirectSource' LFB[FE-MODEL]. If the message is from 2397 FE to CE, the LFB class should be 'RedirectSink'. If the message 2398 is from CE to FE, the LFB class should be 'RedirectSource'. 2400 Instance ID: 2401 Instance ID for the 'RedirectSink' LFB or 'RedirectSource' LFB. 2403 Meta Data TLV: 2404 This is a TLV that specifies meta-data associated with followed 2405 redirected data. The TLV is as follows: 2407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2408 | Type = META-DATA | Length | 2409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2410 | Meta Data ILV | 2411 . . 2412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2413 ~ ... ~ 2414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2415 | Meta Data ILV | 2416 . . 2417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2419 Figure 26 2421 Meta Data ILV: 2422 This is an Identifier-Length-Value format that is used to describe 2423 one meta data. The ILV has the format as: 2425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2426 | Meta Data ID | 2427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2428 | Length | 2429 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2430 | Meta Data Value | 2431 . . 2432 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2434 Where, Meta Data ID is an identifier for the meta data, which is 2435 usually defined by FE-Model[FE-MODEL]. 2437 Usually there are two meta data that are necessary for CE-FE 2438 redirect operation. One is the redirected data type (e.g., IP 2439 packet, TCP packet, or UDP Packet). For an FE->CE redirect 2440 operation, redirected packet type meta data is usually a meta data 2441 specified by a Classifier LFB that filter out redirected packets 2442 from packet stream and sends the packets to Redirect Sink LFB. 2443 For an CE->FE redirect operation, the redirected packet type meta 2444 data is usually directly generated by CE. 2446 Another meta data that should be associated with redirected data 2447 is the port number in a redirect LFB. For a RedirectSink LFB, the 2448 port number meta data tells CE from which port in the lFB the 2449 redirected data come. For a RedriectSource LFB, via the meta 2450 data, CE tells FE which port in the LFB the redirected data should 2451 go out. 2453 Redirect Data TLV 2454 This is a TLV describing one packet of data to be directed via the 2455 redirect operation. The TLV format is as follows: 2457 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2458 | Type = REDIRECTDATA | Length | 2459 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2460 | Redirected Data | 2461 . . 2462 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2464 Redirected Data: 2465 This field presents the whole packet that is to be redirected. 2466 The packet should be 32bits aligned. 2468 6.9 Heartbeat Message 2470 The Heartbeat (HB) Message is used for one ForCES element (FE or CE) 2471 to asynchronously notify one or more other ForCES elements in the 2472 same ForCES NE on its liveness. 2474 A Heartbeat Message is sent by a ForCES element periodically. The 2475 time interval to send the message is set by the Association Setup 2476 Message described in Section 6.1.1. A little different from other 2477 protocol messages, a Heartbeat message is only composed of a common 2478 header, withe the message body left empty. Detailed description of 2479 the message is as below. 2481 Message Transfer Direction: 2482 FE to CE, or CE to FE 2484 Message Header: 2485 The Message Type in the message header is set to MessageType = 2486 'Heartbeat'. The ACK flag in the header SHOULD be set to 2487 'NoACK', meaning no response from receiver(s) is expected by the 2488 message sender. Other values of the ACK flag will always be 2489 ignored by the message receiver. 2491 Message Body: 2492 The message body is empty for the Heartbeat Message. 2494 6.10 Operation Summary 2496 The following tables summarize the operations and their applicabiity 2497 to the messages. 2499 No Operations for the following messages: 2501 Assoc-Setup 2503 Assoc-Setup-Resp 2505 Assoc-Teardown 2507 Heartbeat 2509 +-------------------+-------+------------+--------+-------------+ 2510 | Operation | Query | Query-Resp | Config | config-Resp | 2511 +-------------------+-------+------------+--------+-------------+ 2512 | Set | | | X | X | 2513 | | | | | | 2514 | Delete | | | X | X | 2515 | | | | | | 2516 | Update | | | X | X | 2517 | | | | | | 2518 | Get | X | X | | | 2519 | | | | | | 2520 | Event subscribe | | | X | X | 2521 | | | | | | 2522 | Event unsubscribe | | | X | X | 2523 +-------------------+-------+------------+--------+-------------+ 2524 +-----------+--------------+-------------+------------------+ 2525 | Operation | Packet-Redir | Event-Notif | Event-Notif-Resp | 2526 +-----------+--------------+-------------+------------------+ 2527 | Payload | X | | | 2528 | | | | | 2529 | Report | | X | X | 2530 +-----------+--------------+-------------+------------------+ 2532 7. Protocol Scenarios 2534 7.1 Association Setup state 2536 The associations among CEs and FEs are initiated via Association 2537 setup message from the FE. If a setup request is granted by the CE, 2538 a successful setup response message is sent to the FE. If CEs and 2539 FEs are operating in an insecure environment then the security 2540 association have to be established between them before any 2541 association messages can be exchanged. The TML will take care of 2542 establishing any security associations. 2544 This is followed by capability query, topology query. When the FE is 2545 ready to start forwarding data traffic, it sends a FE UP Event 2546 message to the CE. The CE responds with a FE ACTIVATE State 2547 Maintenance message to ask the FE to go active and start forwarding 2548 data traffic. At this point the association establishment is 2549 complete. These sequences of messages are illustrated in the Figure 2550 below. 2552 FE PL CE PL 2554 | | 2555 | Asso Setup Req | 2556 |---------------------->| 2557 | | 2558 | Asso Setup Resp | 2559 |<----------------------| 2560 | | 2561 | Capability Query | 2562 |<----------------------| 2563 | | 2564 | Query Resp | 2565 |---------------------->| 2566 | | 2567 | Topo Query | 2568 |<----------------------| 2569 | | 2570 | Topo Query Resp | 2571 |---------------------->| 2572 | | 2573 | FE UP Event | 2574 |---------------------->| 2575 | | 2576 | Config-Activate FE | 2577 |<----------------------| 2578 | | 2580 Figure 29: Message exchange between CE and FE to establish an NE 2581 association 2583 On successful completion of this state, the FE joins the NE and is 2584 moved to the Established State or Steady state. 2586 7.2 Association Established state or Steady State 2588 In this state the FE is continously updated or queried. The FE may 2589 also send asynchronous event notifications to the CE or synchronous 2590 heartbeat messages. This continues until a termination (or 2591 deactivation) is initiated by either the CE or FE. Figure below 2592 helps illustrate this state. 2594 FE PL CE PL 2596 | | 2597 | Heart Beat | 2598 |<----------------------| 2599 | | 2600 | Heart Beat | 2601 |---------------------->| 2602 | | 2603 | Config-Subscribe Ev | 2604 |<----------------------| 2605 | | 2606 | Config Resp | 2607 |---------------------->| 2608 | | 2609 | Config-Add LFB Attr | 2610 |<----------------------| 2611 | | 2612 | Config Resp | 2613 |---------------------->| 2614 | | 2615 | Query LFB Stats | 2616 |<----------------------| 2617 | | 2618 | Query Resp | 2619 |---------------------->| 2620 | | 2621 | FE Event Report | 2622 |---------------------->| 2623 | | 2624 | Config-Del LFB Attr | 2625 |<----------------------| 2626 | | 2627 | Config Resp | 2628 |---------------------->| 2629 | | 2630 | Packet Redirect | 2631 |---------------------->| 2632 | | 2633 | Heart Beat | 2634 |<----------------------| 2635 . . 2636 . . 2637 | | 2638 | Config-Activate FE | 2639 |<----------------------| 2640 | | 2642 Figure 30: Message exchange between CE and FE during steady-state 2643 communication 2645 Note that the sequence of messages shown in the figure serve only as 2646 examples and the messages exchange sequences could be different from 2647 what is shown in the figure. Also, note that the protocol scenarios 2648 described in this section do not include all the different message 2649 exchanges which would take place during failover. That is described 2650 in the HA section 8. 2652 8. High Availability Support 2654 The ForCES protocol provides mechanisms for CE redundancy and 2655 failover, in order to support High Availability as defined in 2656 [RFC3654]. FE redundancy and FE to FE interaction is currently out 2657 of scope of this draft. There can be multiple redundant CEs and FEs 2658 in a ForCES NE. However, at any time there can only be one Primary 2659 CE controlling the FEs and there can be multiple secondary CEs. The 2660 FE and the CE PL are aware of the primary and secondary CEs. This 2661 information (primary, secondary CEs) is configured in the FE, CE PLs 2662 during pre-association by FEM, CEM respectively. Only the primary CE 2663 sends Control messages to the FEs. The FE may send its event 2664 reports, redirection packets to only the Primary CE (Report Primary 2665 Mode) or it may send these to both primary and secondary CEs (Report 2666 All Mode). (The latter helps with keeping state between CEs 2667 synchronized, although it does not guarantee synchronization.) This 2668 behavior or HA Modes are configured during Association setup phase 2669 but can be changed by the CE anytime during protocol operation. A 2670 CE-to-CE synchronization protocol will be needed in most cases to 2671 support fast failover, however this will not be defined by the ForCES 2672 protocol. 2674 During a communication failure between the FE and CE (which is caused 2675 due to CE or link reasons, i.e. not FE related), the TML on the FE 2676 will trigger the FE PL regarding this failure. This can also be 2677 detected using the HB messages between FEs and CEs. The FE PL will 2678 send a message (Event Report) to the Secondary CEs to indicate this 2679 failure or the CE PL will detect this and one of the Secondary CEs 2680 takes over as the primary CE for the FE. During this phase, if the 2681 original primary CE comes alive and starts sending any commands to 2682 the FE, the FE should ignore those messages and send an Event to all 2683 CEs indicating its change in Primary CE. Thus the FE only has one 2684 primary CE at a time. 2686 An explicit message (Config message- Move command) from the primary 2687 CE, can also be used to change the Primary CE for an FE during normal 2688 protocol operation. In order to support fast failover, the FE will 2689 establish association (setup msg) as well as complete the capability 2690 exchange with the Primary as well as all the Secondary CEs (in all 2691 scenarios/modes). 2693 These two scenarios (Report All, Report Primary) have been 2694 illustrated in the figures below. 2696 FE CE Primary CE Secondary 2697 | | | 2698 | Asso Estb,Caps exchg | | 2699 1 |<--------------------->| | 2700 | | | 2701 | Asso Estb,Caps|exchange | 2702 2 |<----------------------|------------------->| 2703 | | | 2704 | All msgs | | 2705 3 |<--------------------->| | 2706 | | | 2707 | packet redirection,|events, HBs | 2708 4 |-----------------------|------------------->| 2709 | | | 2710 | FAILURE | 2711 | | 2712 | Event Report (pri CE down) | 2713 5 |------------------------------------------->| 2714 | | 2715 | All Msgs | 2716 6 |------------------------------------------->| 2718 Figure 31: CE Failover for Report All mode 2720 FE CE Primary CE Secondary 2721 | | | 2722 | Asso Estb,Caps exchg | | 2723 1 |<--------------------->| | 2724 | | | 2725 | Asso Estb,Caps|exchange | 2726 2 |<----------------------|------------------->| 2727 | | | 2728 | All msgs | | 2729 3 |<--------------------->| | 2730 | | | 2731 | (HeartBeats| only) | 2732 4 |-----------------------|------------------->| 2733 | | | 2734 | FAILURE | 2735 | | 2736 | Event Report (pri CE down) | 2737 5 |------------------------------------------->| 2738 | | 2739 | All Msgs | 2740 6 |------------------------------------------->| 2742 Figure 32: CE Failover for Report Primary Mode 2744 8.1 Responsibilities for HA 2746 TML level - Transport level: 2748 1. The TML controls logical connection availability and failover. 2750 2. The TML also controls peer HA managements. 2752 At this level, control of all lower layers, for example transport 2753 level (such as IP addresses, MAC addresses etc) and associated links 2754 going down are the role of the TML. 2756 PL Level: 2757 All the other functionality including configuring the HA behavior 2758 during setup, the CEIDs are used to identify primary, secondary CEs, 2759 protocol Messages used to report CE failure (Event Report), Heartbeat 2760 messages used to detect association failure, messages to change 2761 primary CE (config - move), and other HA related operations described 2762 before are the PL responsibility. 2764 To put the two together, if a path to a primary CE is down, the TML 2765 would take care of failing over to a backup path, if one is 2766 available. If the CE is totally unreachable then the PL would be 2767 informed and it will take the appropriate actions described before. 2769 9. Security Considerations 2771 ForCES architecture identified several [Reference Arch] levels of 2772 security. ForCES PL uses security services provided by the ForCES 2773 TML layer. TML layer provides security services such as endpoint 2774 authentication service, message authentication service and 2775 confidentiality service. Endpoint authentication service is invoked 2776 at the time of pre-association connection establishment phase and 2777 message authentication is performed whenever FE or CE receives a 2778 packet from its peer. 2780 Following are the general security mechanism that needs to be in 2781 place for ForCES PL layer. 2783 o Security mechanism are session controlled that is once the 2784 security is turned ON depending upon the chosen security level (No 2785 Security, Authentication only, Confidentiality), it will be in 2786 effect for the entire duration of the session. 2788 o Operator should configure the same security policies for both 2789 primary and backup FE's and CE's (if available). This will ensure 2790 uniform operations, and to avoid unnecessary complexity in policy 2791 configuration. 2793 o ForCES PL endpoints SHOULD pre-established connections with both 2794 primary and backup CE's. This will reduce the security messages 2795 and enable rapid switchover operations for HA. 2797 9.1 No Security 2799 When No security is chosen for ForCES protocol communication, both 2800 endpoint authentication and message authentication service needs be 2801 performed by ForCES PL layer. Both these mechanism are weak and does 2802 not involve cryptographic operation. Operator can choose "No 2803 security" level when the ForCES protocol endpoints are within an 2804 single box. 2806 In order to have interoperable and uniform implementation across 2807 various security levels, each CE and FE endpoint MUST implement this 2808 level. The operations that are being performed for "No security" 2809 level is required even if lower TML security services are being used. 2811 9.1.1 Endpoint Authentication 2813 Each CE and FE PL layer maintain set of associations list as part of 2814 configuration. This is done via CEM and FEM interfaces. FE MUST 2815 connect to only those CE's that are configured via FEM similarly CE 2816 should accept the connection and establish associations for the FE's 2817 which are configured via CEM. CE should validate the FE identifier 2818 before accepting the connection during the pre-association phase. 2820 9.1.2 Message authentication 2822 When CE or FE generates initiates a message, the receiving endpoint 2823 MUST validate the initiator of the message by checking the common 2824 header CE or FE identifiers. This will ensure proper protocol 2825 functioning. We recommend this extra step processing even if the 2826 underlying TLM layer security services. 2828 9.2 ForCES PL and TML security service 2830 This section is applicable if operator wishes to use the TML security 2831 services. ForCES TML layer MUST support one or more security service 2832 such as endpoint authentication service, message authentication 2833 service, confidentiality service as part of TML security layer 2834 functions. It is the responsibility of the operator to select 2835 appropriate security service and configure security policies 2836 accordingly. The details of such configuration is outside the scope 2837 of ForCES PL and is depending upon the type of transport protocol, 2838 nature of connection. 2840 All these configurations should be done prior to starting the CE and 2841 FE. 2843 When certificates-based authentication is being used at TML layer, 2844 the certificate can use ForCES specific naming structure as 2845 certificate names and accordingly the security policies can be 2846 configured at CE and FE. 2848 9.2.1 Endpoint authentication service 2850 When TML security services are enabled. ForCES TML layer performs 2851 endpoint authentication. Security association is established between 2852 CE and FE and is transparent to the ForCES PL layer. 2854 We recommend that FE after establishing the connection with the 2855 primary CE, should establish the security association with the backup 2856 CE (if available). During the switchover operation CE's security 2857 state associated with each SA's are not transferred. SA between 2858 primary CE and FE and backup CE and FE are treated as two separate 2859 SA's. 2861 9.2.2 Message authentication service 2863 This is TML specific operation and is transparent to ForCES PL 2864 layer[TML document]. 2866 9.2.3 Confidentiality service 2868 This is TML specific operation and is transparent to ForCES PL 2869 layer.[TML document] 2871 10. Acknowledgments 2873 The authors of this draft would like to acknowledge and thank the 2874 following: Alex Audu, Steven Blake, Allan DeKok, Ellen M. Deleganes, 2875 Yunfei Guo, Joel M. Halpern, Zsolt Haraszti, Jeff Pickering, 2876 Guangming Wang, Chaoping Wu, Lily L. Yang, and Alistair Munro for 2877 their contributions. We would also like to thank David Putzolu, and 2878 Patrick Droz for their comments and suggestions on the protocol. 2880 11. References 2882 11.1 Normative References 2884 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 2885 June 1999. 2887 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 2888 of IP Control and Forwarding", RFC 3654, November 2003. 2890 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 2891 "Forwarding and Control Element Separation (ForCES) 2892 Framework", RFC 3746, April 2004. 2894 11.2 Informational References 2896 [ACID] Haerder, T. and A. Reuter, "Principles of Transaction- 2897 Orientated Database Recovery", 1983. 2899 [FE-MODEL] 2900 Yang, L., Halpern, J., Gopal, R., DeKok, A., Haraszti, Z., 2901 and S. Blake, "ForCES Forwarding Element Model", 2902 Feb. 2005. 2904 Author's Address 2906 Avri Doria 2907 ETRI 2908 Lulea University of Technology 2909 Lulea 2910 Sweden 2912 Phone: +1 401 663 5024 2913 Email: avri@acm.org 2915 Appendix A. Individual Authors/Editors Contact 2917 Ligang Dong 2918 Zhejiang Gongshang University 2919 149 Jiaogong Road 2920 Hangzhou 310035 2921 P.R.China 2922 Phone: +86-571-88071024 2923 EMail: donglg@mail.hzic.edu.cn 2925 Avri Doria 2926 ETRI 2927 EMail: avri@acm.org 2929 Ram Gopal 2930 Nokia 2931 5, Wayside Road 2932 Burlington MA 01803 2933 USA 2934 Phone: 1-781-993-3685 2935 EMail: ram.gopal@nokia.com 2937 Robert Haas 2938 IBM 2939 Saumerstrasse 4 2940 8803 Ruschlikon 2941 Switzerland 2942 EMail: rha@zurich.ibm.com 2944 Jamal Hadi Salim 2945 Znyx 2946 Ottawa, Ontario 2947 Canada 2948 EMail: hadi@znyx.com 2950 Hormuzd M Khosravi 2951 Intel 2952 2111 NE 25th Avenue 2953 Hillsboro, OR 97124 2954 USA 2955 Phone: +1 503 264 0334 2956 EMail: hormuzd.m.khosravi@intel.com 2957 Weiming Wang 2958 Zhejiang Gongshang University 2959 149 Jiaogong Road 2960 Hangzhou 310035 2961 P.R.China 2962 Phone: +86-571-88057712 2963 EMail: wmwang@mail.hzic.edu.cn 2965 Appendix B. IANA considerations 2967 tbd 2969 Appendix C. Forces Protocol LFB schema 2971 The schema described below conforms to the LFB schema (language?) 2972 described in Forces Model draft[FE-MODEL] 2974 2979 2980 2981 2982 FEPO 2983 1 2984 2985 The FE Protocol Object 2986 2987 1.0 2988 baseclass 2989 2990 2991 HBstate 2992 2 2993 2994 Heartbeat event status(yes/no) 2995 2996 boolean 2997 2998 2999 3000 3001 SupportableVersions 3002 1 3003 3004 the table of ForCES versions that FE supports 3005 3006 3007 u8 3008 3009 3010 3011 3012 3013 HBI 3014 3 3015 Heartbeat Interval in millisecs 3016 uint32 3018 3019 3020 HBDI 3021 4 3022 Heartbeat Dead Interval in millisecs 3023 uint32 3024 3025 3026 CurrentRunningVersion 3027 5 3028 Currently running ForCES version 3029 u8 3030 3031 3032 3033 3034 3036 C.1 Events 3038 At the moment only one event, HBstate, can be subscribed to by the 3039 CE. 3041 By subscribing to the HBstate event, the CE infact kicks the FE into 3042 motion to start issuing heartbeats. 3044 C.2 Capabilities 3046 At the moment only the SupportableVersions capability is owned by 3047 this LFB. 3049 Supportable Versions enumerates all ForCES versions that an FE 3050 supports. 3052 C.3 Attributes 3054 C.3.1 HBI 3056 This attribute carries the Heartbeat Interval of the heartbeat from 3057 the FE -> CE in millisecs. The value of this interval is by default 3058 set by the FE but could be overwritten in the association setup by 3059 the CE. 3061 TBD (this really belongs in the protocol draft but here for capture 3062 purposes: 3064 Define it as simply that the CE and FE must hear from each other at 3065 the configured interval. The FE on her side generates a heartbeat 3066 notification if he has nothing else to say. In otehr words, The lack 3067 of any messages from the CE to which the FE responded to after a 3068 period of HBI will result in a FE firing a HB message. The lack of 3069 any message within DeadInterval will force the FE to ask for an ACK 3070 for its HB message (by setting the ACK flag in the header). 3072 Other adaptive heartbeats schemes which could be used: have the CE 3073 adjust the FE timers depending on the number of FEs present. 3074 Example, its 1 sec for upto 100 FEs and 2 seconds for [101,200] 4 3075 seconds interval for > 200 nodes etc ... Some adaptation of this is 3076 used by mmusic mbus protocol. 3078 C.3.2 HBDI 3080 This attribute carries the Heartbeat Dead Interval in millisecs. 3082 TBD: 3084 The original goal for HBDI was for HA purposes - to discover if the 3085 CE is still around by sending a heartbeat message to the CE with an 3086 ACK flag in the mainheader to request for a response. This hasnt 3087 been discussed in details yet; however, the general view at the time 3088 was for the FE to associate (failover) to another CE after that 3089 deadinterval period of not hearing from the CE - as defined by policy 3090 which resides in that same LFB definition. Two such failover 3091 methodologies are mentiooned briefly infact in the protocol draft but 3092 since the current attributes are unknown, the details are missing 3093 from the xml. 3095 C.3.3 CurrentRunningVersion 3097 This attribute describes which version of ForCES is currently 3098 running. 3100 Appendix D. Use Cases 3102 Assume LFB with following attributes for the following use cases. 3104 foo1, type u32, ID = 1 3106 foo2, type u32, ID = 2 3108 table1: type array, ID = 3 3109 elements are: 3110 t1, type u32, ID = 1 3111 t2, type u32, ID = 2 // index into table 2 3112 KEY: nhkey, ID = 1, V = t2 3114 table2: type array, ID = 4 3115 elements are: 3116 j1, type u32, ID = 1 3117 j2, type u32, ID = 2 3118 KEY: akey, ID = 1, V = { j1,j2 } 3120 table3: type array, ID = 5 3121 elements are: 3122 someid, type u32, ID = 1 3123 name, type string variable sized, ID = 2 3125 table4: type array, ID = 6 3126 elements are: 3127 j1, type u32, ID = 1 3128 j2, type u32, ID = 2 3129 j3, type u32, ID = 3 3130 j4, type u32, ID = 4 3131 KEY: mykey, ID = 1, V = { j1} 3133 table5: type array, ID = 7 3134 elements are: 3135 p1, type u32, ID = 1 3136 p2, type array, ID = 2, array elements of type-X 3138 Type-X: 3139 x1, ID 1, type u32 3140 x2, ID2 , type u32 3141 KEY: tkey, ID = 1, V = { x1} 3143 All examples will show an attribute suffixed with "v" or "val" to 3144 indicate the value of the referenced attribute. example for attribute 3145 foo2, foo1v or foo1value will indicate the value of foo1. In the 3146 case where F_SEL** are missing (bits equal to 00) then the flags will 3147 not show any selection. 3149 1. To get foo1 3151 OPER = GET-TLV 3152 Path-data TLV: IDCount = 1, IDs = 1 3153 Result: 3154 OPER = GET-RESPONSE-TLV 3155 Path-data-TLV: 3156 flags=0, IDCount = 1, IDs = 1 3157 DATARAW-TLV L = 4+4, V = foo1v 3159 2. To set foo2 to 10 3161 OPER = SET-REPLACE-TLV 3162 Path-data-TLV: 3163 flags = 0, IDCount = 1, IDs = 2 3164 DATARAW TLV: L = 4+4, V=10 3166 Result: 3167 OPER = SET-RESPONSE-TLV 3168 Path-data-TLV: 3169 flags = 0, IDCount = 1, IDs = 2 3170 RESULT-TLV 3172 3. To dump table2 3174 OPER = GET-TLV 3175 Path-data-TLV: 3176 IDCount = 1, IDs = 4 3177 Result: 3178 OPER = GET-RESPONSE-TLV 3179 Path-data-TLV: 3180 flags = 0, IDCount = 1, IDs = 4 3181 DATARAW=TLV: L = XXX, V= 3182 a series of: index, j1value,j2value entries 3183 representing the entire table 3185 4. Note: One should be able to take a GET-RESPONSE-TLV and convert 3186 it to a SET-REPLACE-TLV. If the result in the above example is 3187 sent back in a SET-REPLACE-TLV, (instead of a GET-RESPONSE_TLV) 3188 then the entire contents of the table will be replaced at that 3189 point. 3191 5. Multiple operations Example. To create entry 0-5 of table2 3192 (Ignore error conditions for now) 3194 OPER = SET-CREATE-TLV 3195 Path-data-TLV: 3196 flags = 0 , IDCount = 1, IDs=4 3197 PATH-DATA-TLV 3198 flags = 0, IDCount = 1, IDs = 0 3199 DATARAW-TLV containing j1, j2 value for entry 0 3200 PATH-DATA-TLV 3201 flags = 0, IDCount = 1, IDs = 1 3202 DATARAW-TLV containing j1, j2 value for entry 1 3203 PATH-DATA-TLV 3204 flags = 0, IDCount = 1, IDs = 2 3205 DATARAW-TLV containing j1, j2 value for entry 2 3206 PATH-DATA-TLV 3207 flags = 0, IDCount = 1, IDs = 3 3208 DATARAW-TLV containing j1, j2 value for entry 3 3209 PATH-DATA-TLV 3210 flags = 0, IDCount = 1, IDs = 4 3211 DATARAW-TLV containing j1, j2 value for entry 4 3212 PATH-DATA-TLV 3213 flags = 0, IDCount = 1, IDs = 5 3214 DATARAW-TLV containing j1, j2 value for entry 5 3216 Result: 3217 OPER = SET-RESPONSE-TLV 3218 Path-data-TLV: 3219 flags = 0 , IDCount = 1, IDs=4 3220 PATH-DATA-TLV 3221 flags = 0, IDCount = 1, IDs = 0 3222 RESULT-TLV 3223 PATH-DATA-TLV 3224 flags = 0, IDCount = 1, IDs = 1 3225 RESULT-TLV 3226 PATH-DATA-TLV 3227 flags = 0, IDCount = 1, IDs = 2 3228 RESULT-TLV 3229 PATH-DATA-TLV 3230 flags = 0, IDCount = 1, IDs = 3 3231 RESULT-TLV 3232 PATH-DATA-TLV 3233 flags = 0, IDCount = 1, IDs = 4 3234 RESULT-TLV 3235 PATH-DATA-TLV 3236 flags = 0, IDCount = 1, IDs = 5 3237 RESULT-TLV 3239 6. Block operations (with holes) example. Replace entry 0,2 of 3240 table2 3242 OPER = SET-REPLACE-TLV 3243 Path-data TLV: 3244 flags = 0 , IDCount = 1, IDs=4 3245 PATH-DATA-TLV 3246 flags = 0, IDCount = 1, IDs = 0 3247 DATARAW-TLV containing j1, j2 value for entry 0 3248 PATH-DATA-TLV 3249 flags = 0, IDCount = 1, IDs = 2 3250 DATARAW-TLV containing j1, j2 value for entry 2 3252 Result: 3253 OPER = SET-REPLACE-TLV 3254 Path-data TLV: 3255 flags = 0 , IDCount = 1, IDs=4 3256 PATH-DATA-TLV 3257 flags = 0, IDCount = 1, IDs = 0 3258 RESULT-TLV 3259 PATH-DATA-TLV 3260 flags = 0, IDCount = 1, IDs = 2 3261 RESULT-TLV 3263 7. Getting rows example. Get first entry of table2. 3265 OPER = GET-TLV 3266 Path-data TLV: 3267 IDCount = 2, IDs=4.0 3269 Result: 3270 OPER = GET-RESPONSE-TLV 3271 Path-data TLV: 3272 IDCount = 2, IDs=4.0 3273 DATARAW TLV, Length = XXX, V = 3274 j1value,j2value entry 3276 8. Get entry 0-5 of table2. 3278 OPER = GET-TLV 3279 Path-data-TLV: 3280 flags = 0, IDCount = 1, IDs=4 3281 PATH-DATA-TLV 3282 flags = 0, IDCount = 1, IDs = 0 3283 PATH-DATA-TLV 3284 flags = 0, IDCount = 1, IDs = 1 3285 PATH-DATA-TLV 3286 flags = 0, IDCount = 1, IDs = 2 3287 PATH-DATA-TLV 3288 flags = 0, IDCount = 1, IDs = 3 3289 PATH-DATA-TLV 3290 flags = 0, IDCount = 1, IDs = 4 3291 PATH-DATA-TLV 3292 flags = 0, IDCount = 1, IDs = 5 3294 Result: 3295 OPER = GET-RESPONSE-TLV 3296 Path-data-TLV: 3297 flags = 0, IDCount = 1, IDs=4 3298 PATH-DATA-TLV 3299 flags = 0, IDCount = 1, IDs = 0 3300 DATARAW-TLV containing j1value j2value 3301 PATH-DATA-TLV 3302 flags = 0, IDCount = 1, IDs = 1 3303 DATARAW-TLV containing j1value j2value 3304 PATH-DATA-TLV 3305 flags = 0, IDCount = 1, IDs = 2 3306 DATARAW-TLV containing j1value j2value 3307 PATH-DATA-TLV 3308 flags = 0, IDCount = 1, IDs = 3 3309 DATARAW-TLV containing j1value j2value 3310 PATH-DATA-TLV 3311 flags = 0, IDCount = 1, IDs = 4 3312 DATARAW-TLV containing j1value j2value 3313 PATH-DATA-TLV 3314 flags = 0, IDCount = 1, IDs = 5 3315 DATARAW-TLV containing j1value j2value 3317 9. Create a row in table2, index 5. 3319 OPER = SET-CREATE-TLV 3320 Path-data-TLV: 3321 flags = 0, IDCount = 2, IDs=4.5 3322 DATARAW TLV, Length = XXX 3323 j1value,j2value 3325 Result: 3326 OPER = SET-RESPONSE-TLV 3327 Path-data TLV: 3328 flags = 0, IDCount = 1, IDs=4.5 3329 RESULT-TLV 3331 10. An example of "create and give me an index" Assuming we asked 3332 for verbose response back in the main message header. 3334 OPER = SET-CREATE-TLV 3335 Path-data -TLV: 3336 flags = FIND-EMPTY, IDCount = 1, IDs=4 3337 DATARAW TLV, Length = XXX 3338 j1value,j2value 3340 Result 3341 If 7 were the first unused entry in the table: 3342 OPER = SET-RESPONSE 3343 Path-data TLV: 3344 flags = 0, IDCount = 2, IDs=4.7 3345 RESULT-TLV indicating success, and 3346 DATARAW-TLV, Length = XXX j1value,j2value 3348 11. Dump contents of table1. 3350 OPER = GET-TLV 3351 Path-data TLV: 3352 flags = 0, IDCount = 1, IDs=3 3354 Result: 3355 OPER = GET-RESPONSE-TLV 3356 Path-data TLV 3357 flags = 0, IDCount = 1, IDs=3 3358 DATARAW TLV, Length = XXXX 3359 (depending on size of table1) 3360 index, t1value, t2value 3361 index, t1value, t2value 3362 . 3364 . 3365 . 3367 12. Using Keys. Get row entry from table4 where j1=100. Recall, j1 3368 is a defined key for this table and its keyid is 1. 3370 OPER = GET-TLV 3371 Path-data-TLV: 3372 flags = F_SELKEY IDCount = 1, IDs=6 3373 KEYINFO-TLV = KEYID=1, KEY_DATA=100 3375 Result: 3376 If j1=100 was at index 10 3377 OPER = GET-RESPONSE-TLV 3378 Path-data TLV: 3379 flags = 0, IDCount = 1, IDs=6.10 3380 DATARAW TLV, Length = XXXX 3381 j1value,j2value, j3value, j4value 3383 13. Delete row with KEY match (j1=100, j2=200) in table 2. Note 3384 that the j1,j2 pair are a defined key for the table 2. 3386 OPER = DEL-TLV 3387 Path-data TLV: 3388 flags = F_SELKEY IDCount = 1, IDs=4 3389 KEYINFO TLV: {KEYID =1 KEY_DATA=100,200} 3391 Result: 3392 If (j1=100, j2=200) was at entry 15: 3393 OPER = DELETE-RESPONSE-TLV 3394 Path-data TLV: 3395 flags = 0 IDCount = 2, IDs=4.15 3396 RESULT-TLV (with DATARAW if verbose) 3398 14. Dump contents of table3. It should be noted that this table has 3399 a column with element name that is variable sized. The purpose 3400 of this use case is to show how such an element is to be 3401 encoded. 3403 OPER = GET-TLV 3404 Path-data-TLV: 3405 flags = 0 IDCount = 1, IDs=5 3407 Result: 3408 OPER = GET-RESPONSE-TLV 3409 Path-data TLV: 3410 flags = 0 IDCount = 1, IDs=5 3411 DATARAW TLV, Length = XXXX 3412 index, someidv, TLV: T=DATARAW, L = 4+strlen(namev), 3413 V = namev 3414 index, someidv, TLV: T=DATARAW, L = 4+strlen(namev), 3415 V = namev 3416 index, someidv, TLV: T=DATARAW, L = 4+strlen(namev), 3417 V = namev 3418 index, someidv, TLV: T=DATARAW, L = 4+strlen(namev), 3419 V = namev 3420 . 3421 . 3422 . 3424 15. Multiple atomic operations. 3426 16. Note: This emulates adding a new nexthop entry and then 3427 atomically updating the L3 entries pointing to an old NH to 3428 point to a new one. The assumption is both tables are in the 3429 same LFB 3431 17. Main header has atomic flag set and we are request for verbose/ 3432 full results back; Two operations on the LFB instance, both are 3433 SET operations. 3435 //Operation 1: Add a new entry to table2 index #20. 3436 OPER = SET-CREATE-TLV 3437 Path-TLV: 3438 flags = 0, IDCount = 2, IDs=4.20 3439 DATARAW TLV, V= j1value,j2value 3441 // Operation 2: Update table1 entry which 3442 // was pointing with t2 = 10 to now point to 20 3443 OPER = SET-REPLACE-TLV 3444 Path-data-TLV: 3445 flags = F_SELKEY, IDCount = 1, IDs=3 3446 KEYINFO = KEYID=1 KEY_DATA=10 3447 Path-data-TLV 3448 flags = 0 IDCount = 1, IDs=2 3449 DATARAW TLV, V= 20 3451 Result: 3452 //first operation, SET 3453 OPER = SET-RESPONSE-TLV 3454 Path-data-TLV 3455 flags = 0 IDCount = 3, IDs=4.20 3456 RESULT-TLV code = success 3457 DATARAW TLV, V = j1value,j2value 3458 // second opertion SET - assuming entry 16 was updated 3459 OPER = SET-RESPONSE-TLV 3460 Path-data TLV 3461 flags = 0 IDCount = 2, IDs=3.16 3462 Path-Data TLV 3463 flags = 0 IDCount = 1, IDs = 2 3464 SET-RESULT-TLV code = success 3465 DATARAW TLV, Length = XXXX v=20 3466 // second opertion SET 3467 OPER = SET-RESPONSE-TLV 3468 Path-data TLV 3469 flags = 0 IDCount = 1, IDs=3 3470 KEYINFO = KEYID=1 KEY_DATA=10 3471 Path-Data TLV 3472 flags = 0 IDCount = 1, IDs = 2 3473 SET-RESULT-TLV code = success 3474 DATARAW TLV, Length = XXXX v=20 3476 18. Selective setting (Example posted by Weiming). On table 4 -- 3477 for indices 1, 3, 5, 7, and 9. Replace j1 to 100, j2 to 200, j3 3478 to 300. Leave j4 as is. 3480 PER = SET-REPLACE-TLV 3481 Path-data TLV 3482 flags = 0, IDCount = 1, IDs = 6 3483 Path-data TLV 3484 flags = 0, IDCount = 1, IDs = 1 3485 Path-data TLV 3486 flags = 0, IDCount = 1, IDs = 1 3487 DATARAW TLV, Length = XXXX, V = {100} 3488 Path-data TLV 3489 flags = 0, IDCount = 1, IDs = 2 3490 DATARAW TLV, Length = XXXX, V = {200} 3491 Path-data TLV 3492 flags = 0, IDCount = 1, IDs = 3 3493 DATARAW TLV, Length = XXXX, V = {300} 3494 Path-data TLV 3495 flags = 0, IDCount = 1, IDs = 3 3496 Path-data TLV 3497 flags = 0, IDCount = 1, IDs = 1 3498 DATARAW TLV, Length = XXXX, V = {100} 3499 Path-data TLV 3500 flags = 0, IDCount = 1, IDs = 2 3501 DATARAW TLV, Length = XXXX, V = {200} 3502 Path-data TLV 3503 flags = 0, IDCount = 1, IDs = 3 3504 DATARAW TLV, Length = XXXX, V = {300} 3505 Path-data TLV 3506 flags = 0, IDCount = 1, IDs = 5 3507 Path-data TLV 3508 flags = 0, IDCount = 1, IDs = 1 3509 DATARAW TLV, Length = XXXX, V = {100} 3510 Path-data TLV 3511 flags = 0, IDCount = 1, IDs = 2 3512 DATARAW TLV, Length = XXXX, V = {200} 3513 Path-data TLV 3514 flags = 0, IDCount = 1, IDs = 3 3515 DATARAW TLV, Length = XXXX, V = {300} 3516 Path-data TLV 3517 flags = 0, IDCount = 1, IDs = 7 3518 Path-data TLV 3519 flags = 0, IDCount = 1, IDs = 1 3520 DATARAW TLV, Length = XXXX, V = {100} 3521 Path-data TLV 3522 flags = 0, IDCount = 1, IDs = 2 3523 DATARAW TLV, Length = XXXX, V = {200} 3524 Path-data TLV 3525 flags = 0, IDCount = 1, IDs = 3 3526 DATARAW TLV, Length = XXXX, V = {300} 3527 Path-data TLV 3528 flags = 0, IDCount = 1, IDs = 9 3529 Path-data TLV 3530 flags = 0, IDCount = 1, IDs = 1 3531 DATARAW TLV, Length = XXXX, V = {100} 3532 Path-data TLV 3533 flags = 0, IDCount = 1, IDs = 2 3534 DATARAW TLV, Length = XXXX, V = {200} 3535 Path-data TLV 3536 flags = 0, IDCount = 1, IDs = 3 3537 DATARAW TLV, Length = XXXX, V = {300} 3539 Non-verbose response mode shown: 3541 OPER = SET-RESPONSE-TLV 3542 Path-data TLV 3543 flags = 0, IDCount = 1, IDs = 6 3544 Path-data TLV 3545 flags = 0, IDCount = 1, IDs = 1 3546 Path-data TLV 3547 flags = 0, IDCount = 1, IDs = 1 3548 RESULT-TLV 3549 Path-data TLV 3550 flags = 0, IDCount = 1, IDs = 2 3551 RESULT-TLV 3552 Path-data TLV 3553 flags = 0, IDCount = 1, IDs = 3 3554 RESULT-TLV 3555 Path-data TLV 3556 flags = 0, IDCount = 1, IDs = 3 3557 Path-data TLV 3558 flags = 0, IDCount = 1, IDs = 1 3559 RESULT-TLV 3560 Path-data TLV 3561 flags = 0, IDCount = 1, IDs = 2 3562 RESULT-TLV 3563 Path-data TLV 3564 flags = 0, IDCount = 1, IDs = 3 3565 RESULT-TLV 3566 Path-data TLV 3567 flags = 0, IDCount = 1, IDs = 5 3568 Path-data TLV 3569 flags = 0, IDCount = 1, IDs = 1 3570 RESULT-TLV 3571 Path-data TLV 3572 flags = 0, IDCount = 1, IDs = 2 3573 RESULT-TLV 3574 Path-data TLV 3575 flags = 0, IDCount = 1, IDs = 3 3576 RESULT-TLV 3577 Path-data TLV 3578 flags = 0, IDCount = 1, IDs = 7 3579 Path-data TLV 3580 flags = 0, IDCount = 1, IDs = 1 3581 RESULT-TLV 3582 Path-data TLV 3583 flags = 0, IDCount = 1, IDs = 2 3584 RESULT-TLV 3585 Path-data TLV 3586 flags = 0, IDCount = 1, IDs = 3 3587 RESULT-TLV 3588 Path-data TLV 3589 flags = 0, IDCount = 1, IDs = 9 3590 Path-data TLV 3591 flags = 0, IDCount = 1, IDs = 1 3592 RESULT-TLV 3593 Path-data TLV 3594 flags = 0, IDCount = 1, IDs = 2 3595 RESULT-TLV 3596 Path-data TLV 3597 flags = 0, IDCount = 1, IDs = 3 3598 RESULT-TLV 3600 19. Manipulation of table of table examples. Get x1 from table10 3601 row with index 4, inside table5 entry 10 3603 operation = GET-TLV 3604 Path-data-TLV 3605 flags = 0 IDCount = 5, IDs=7.10.2.4.1 3607 Results: 3608 operation = GET-RESPONSE-TLV 3609 Path-data-TLV 3610 flags = 0 IDCount = 5, IDs=7.10.2.4.1 3611 DATARAW TLV: L=XXXX, V = {x1 value} 3613 20. From table5's row 10 table10, get X2s based on on the value of 3614 x1 equlaing 10 (recal x1 is KeyID 1) 3616 operation = GET-TLV 3617 Path-data-TLV 3618 flag = F_SELKEY, IDCount=3, IDS = 7.10.2 3619 KEYINFO TLV, KEYID = 1, KEYDATA = 10 3620 Path-data TLV 3621 IDCount = 1, IDS = 2 //select x2 3623 Results: 3624 If x1=10 was at entry 11: 3625 operation = GET-RESPONSE-TLV 3626 Path-data-TLV 3627 flag = 0, IDCount=5, IDS = 7.10.2.11 3628 Path-data TLV 3629 flags = 0 IDCount = 1, IDS = 2 3630 DATARAW TLV: L=XXXX, V = {x2 value} 3632 21. Further example of table of table 3634 Consider table 6 which is defined as: 3635 table6: type array, ID = 8 3636 elements are: 3637 p1, type u32, ID = 1 3638 p2, type array, ID = 2, array elements of type type-A 3640 type-A: 3641 a1, type u32, ID 1, 3642 a2, type array ID2 ,array elements of type type-B 3644 type-B: 3645 b1, type u32, ID 1 3646 b2, type u32, ID 2 3648 So lets say we wanted to set by replacing: 3649 table6.10.p1 to 111 3650 table6.10.p2.20.a1 to 222 3651 table6.10.p2.20.a2.30.b1 to 333 3653 in one message and one operation. 3655 There are two ways to do this: 3656 a) using nesting 3658 operation = SET-REPLACE-TLV 3659 Path-data-TLV 3660 flags = 0 IDCount = 2, IDs=6.10 3661 Path-data-TLV 3662 flags = 0, IDCount = 1, IDs=1 3663 DATARAW TLV: L=XXXX, 3664 V = {111} 3665 Path-data-TLV 3666 flags = 0 IDCount = 2, IDs=2.20 3667 Path-data-TLV 3668 flags = 0, IDCount = 1, IDs=1 3669 DATARAW TLV: L=XXXX, 3670 V = {222} 3671 Path-data TLV : 3672 flags = 0, IDCount = 3, IDs=2.30.1 3673 DATARAW TLV: L=XXXX, 3674 V = {333} 3675 Result: 3676 operation = SET-RESPONSE-TLV 3677 Path-data-TLV 3678 flags = 0 IDCount = 2, IDs=6.10 3679 Path-data-TLV 3680 flags = 0, IDCount = 1, IDs=1 3681 RESULT-TLV 3682 Path-data-TLV 3683 flags = 0 IDCount = 2, IDs=2.20 3684 Path-data-TLV 3685 flags = 0, IDCount = 1, IDs=1 3686 RESULT-TLV 3687 Path-data TLV : 3688 flags = 0, IDCount = 3, IDs=2.30.1 3689 RESULT-TLV 3690 b) using a flat path data 3691 operation = SET-REPLACE-TLV 3692 Path-data TLV : 3693 flags = 0, IDCount = 3, IDs=6.10.1 3694 DATARAW TLV: L=XXXX, 3695 V = {111} 3696 Path-data TLV : 3697 flags = 0, IDCount = 5, IDs=6.10.1.20.1 3698 DATARAW TLV: L=XXXX, 3699 V = {222} 3700 Path-data TLV : 3701 flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1 3702 DATARAW TLV: L=XXXX, 3703 V = {333} 3704 Result: 3705 operation = SET-REPLACE-TLV 3706 Path-data TLV : 3707 flags = 0, IDCount = 3, IDs=6.10.1 3708 RESULT-TLV 3709 Path-data TLV : 3711 flags = 0, IDCount = 5, IDs=6.10.1.20.1 3712 RESULT-TLV 3713 Path-data TLV : 3714 flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1 3715 RESULT-TLV 3717 22. Get a whole LFB (all its attributes etc). 3719 23. For example, at startup a CE might well want the entire FE 3720 OBJECT LFB. So, in a request targetted at class 1, instance 1, 3721 one might find: 3723 operation = GET-TLV 3724 Path-data-TLV 3725 flags = 0 IDCount = 0 3727 result: 3728 operation = GET-RESPONSE-TLV 3729 Path-data-TLV 3730 flags = 0 IDCount = 0 3731 DATARAW encoding of the FE Object LFB 3733 Appendix E. Implementation Notes 3735 E.1 TML considerations 3737 Having separated the PL from the TML layer, it became clear that the 3738 TML layer needed to understand the desires of the PL layer to service 3739 it. Example: How does the TML layer map prioritization or 3740 reliability needs of a PL message? To see the challenge involved, 3741 assume that all of the FE TML, FE PL, CE TML and CE PL are 3742 implemented by different authors probably belonging to different 3743 organizations. Three implementation alternatives were discussed. 3745 As an example, consider a TML which defines that PL messages needing 3746 reliability get sent over a TCP connection; then TML-PL interfaces 3747 are: 3749 o PL to call a special API: example send_reliable(msg) which is 3750 translated by the TML to mean send via TCP. 3752 o PL to call a generic API: example send(msg) with explicit msg 3753 flags turned to say "reliability needed" and the TML translates 3754 this to mean send via TCP. 3756 o PL sends the Forces Messages such a message is inferred to mean 3757 send via TCP by the TML. 3759 in #1 and #2 the msg includes a ForCES msg with metadata flags which 3760 ar consumed by the TML layer. 3762 #3 is a technique that will be referred as inference-by-TML 3763 technique. It simplifies the standardization effort since both #1 3764 and #2 will require standardization of an API. Two ideas discussed 3765 for TML inference of PL messages are: 3767 1. Looking at the flags in the header. 3769 2. Looking at the message type. 3771 #1 and #2 can still be used if a single organization implements both 3772 (PL and TML) layers. It is also reasonable that one organization 3773 implements the TML and provides an abstraction to another 3774 organization to implement a PL layer on. 3776 E.1.1 PL Flag inference by TML 3778 1. Reliability 3779 This could be "signalled" from the PL to the TML via the ACK 3780 flag. The message type as well could be used to indicate this. 3782 2. No reliability 3783 Could be signalled via missing ACK flag. The message type as 3784 well could be used to indicate this. 3786 3. Priorities 3787 A remapping to be defined via the FEM or the CEM interface 3788 depending on the number of TML priorities available. 3790 4. Addressing 3791 This is TML specific. For example a TML that is capable of 3792 multicast transport may map a multicast PL ID to a multicast 3793 transport address. 3795 5. Event notifications 3796 The TML must be able to send to the PL notifications. 3798 1. The TML should be able to send Transport level congestion 3799 notifications to the PL. 3801 2. Link events for HA purposes if configuration requires it 3803 3. Events that will trigger PL layer events from the TML. 3804 As an example, an HA event at the TML layer like a failure of 3805 CE detected at TML on the FE may belong to this. In this 3806 case, a PL event msg will be triggered and sent to CE. 3808 4. Events that are intrinsic to the same CE or FE a TML is 3809 located. These will not trigger any PL msg, instead, they 3810 just act as notification to PL core (FE object). The 3811 congestion event generated at the transmission source side 3812 may belong to this, because it usually only needs to tell the 3813 upper PL at the same side rather than the opposite side that 3814 congestion has happened along the path. E.g., a congestion 3815 event at CE TML layer only need to tell CE PL of this, rather 3816 than the opposite FE via a PL msg. 3818 E.1.2 Message type inference to Mapping at the TML 3820 In this case one would define the desires of the different message 3821 types and what they expect from the TML. For example: 3823 1. Association Setup, Teardown, Config, Query the PL will expect the 3824 following services from TML: Reliable delivery and highest 3825 prioritization. 3827 2. Packet Redirect, HB Message Types, and Event Reports the PL will 3828 require the following services from TML: Medium Prioritization, 3829 and notifications when excessive losses are reached. 3831 Appendix F. changes between -03 and -04 3833 1. Issue 9: changes to definiton of LFB type 3835 2. Issue 21: removed timeliness list item since the references to 3836 obsoleting messages was removed and it was the only content in 3837 the section. 3839 3. Issue 22 & 56: changed msg_Config_Repsonse message layout. 3840 changed defintion of RESULT-TLV 3842 4. Issue 23: closed 3844 5. Issue 24: removed all reference to CE-LFB 3846 6. Issue 25: closed 3848 7. Issue 26: Replaced Teardown TLV 3850 8. Issue 28: Added clarification of RangeMark 0xffffffff 3852 9. Issue 30: closed 3854 10. Issue 32: Inserted new Redirect Message text. 3856 11. Issue 34: Added text on Priority field 3858 12. Issue 35: Removed reference to FE TML events 3860 13. Issue 36: Added explanation for FE and CE Failover and restart 3861 policy 3863 14. Issue 37: Indicated that the MAY be one and only one LFB as 3864 opposed to MUST be one and only one. 3866 15. Issue 38: Editorial remove forgotten editorial note. 3868 16. Issue 41: Closed 3870 17. Issue 44: Replaced FE, CE, and FE protocol LFB introduction with 3871 new text. 3873 18. Issue 45: Replaced inter-TML with explicit text 3875 19. Issue 46: Added clarifying text on priority levels. 3877 20. Issue 48: fixed indent editorial. Replaced SELECTOR flags with 3878 PATH flags 3880 21. Issue 49: Changes to Association setup message, clarify use of 3881 SET and GET-RESPONSE 3883 22. Issue 51: Replace Event with Report in Command summary table 3885 23. Issue 52: Change to Association Setup message 3887 24. Issue 55: updated text on transaction types 3889 25. Issue 56: Added error for Assocition Setup Repsonse and Config 3890 Response Message 3892 Appendix G. changes between -02 and -03 3894 1. Remove most all editorial notes and replaced them with entries in 3895 tracker. 3897 2. Marked TBD with tracker issue number 3899 3. In section on config message replaced GET in the example figures 3900 to SET 3902 4. ISSUE: 12 - replaced Command with Message type in Common Header 3904 5. ISSUE: 12 - in Data Packing Rules replaced 'sans' with 'without 3905 the' 3907 6. Removed an uncountably large multitude of tabs that were making 3908 xml2rfc-1.29 choke. 3910 7. fixed many nits 3912 Appendix H. Changes between -01 and -02 3914 1. Renamed definitions.xml to Definitions.xml 3916 2. Added Alistair Munro to acks list. 3918 3. path-data additions + full BNF conformant to RFC 2234 3920 4. Appendix C with examples. #3 and #4 are the biggest changes 3921 incorporate many many days of discussion. 3923 5. appendix with beginings of FE protocol LFB xml. The FE Object 3924 is referenced as being in the Model draft 3926 6. Some cosmetic things like: 3928 1. For readability, introducing section 'protocol construction' 3929 which now encapsulates 'Protocol Messages' (which used to be 3930 a top section) 3932 2. A new subsection "protocol grammar' goes underneath the same 3933 section. 3935 3. added TLV definition subsection 3937 4. Many new "editorial notes" 3939 7. Closure of all but one outstanding issue from the tracker. 3941 8. Any other cosmetic changes posted (Hormuzd, David, Robert, 3942 Avri). 3944 9. Rearranged text a little to introduce new sections to make text 3945 more readable 3947 10. Rewrote the atomicity section (still under construction input 3948 text on ACID from Robert and Alistair) 3950 11. fixed up the model reference to have all authors and added acid 3951 reference 3953 12. Weiming's updates to query and event msgs to add path-data. 3955 Appendix I. Changes between -00 and -01 3957 1. Major Protocol changes 3959 * Restructured message format to apply operation to LFB as 3960 opposed to having operation be the primary organizing 3961 principle 3963 * Worked with model team to bring the draft into harmony with 3964 their model approach 3966 2. Document changes 3968 * Replaced FE protocol Object and FE Object sections with 3969 combined section on FE, CE and FE protocol LFBs 3971 * Removed minor version id 3973 * Added Header flags 3975 * Added BNF description of message structure 3977 * Added tree structure description of PDUs 3979 * Added section on each type of LFB 3981 * Added structural description of each message 3983 * Moved query messages section to come after config message 3984 section 3986 * Replace state maintenance section 3988 * Added section with tables showing the operations relevant to 3989 particular messages 3991 * Reworked HA section 3993 * Many spelling and grammatical corrections 3995 Intellectual Property Statement 3997 The IETF takes no position regarding the validity or scope of any 3998 Intellectual Property Rights or other rights that might be claimed to 3999 pertain to the implementation or use of the technology described in 4000 this document or the extent to which any license under such rights 4001 might or might not be available; nor does it represent that it has 4002 made any independent effort to identify any such rights. Information 4003 on the procedures with respect to rights in RFC documents can be 4004 found in BCP 78 and BCP 79. 4006 Copies of IPR disclosures made to the IETF Secretariat and any 4007 assurances of licenses to be made available, or the result of an 4008 attempt made to obtain a general license or permission for the use of 4009 such proprietary rights by implementers or users of this 4010 specification can be obtained from the IETF on-line IPR repository at 4011 http://www.ietf.org/ipr. 4013 The IETF invites any interested party to bring to its attention any 4014 copyrights, patents or patent applications, or other proprietary 4015 rights that may cover technology that may be required to implement 4016 this standard. Please address the information to the IETF at 4017 ietf-ipr@ietf.org. 4019 The IETF has been notified of intellectual property rights claimed in 4020 regard to some or all of the specification contained in this 4021 document. For more information consult the online list of claimed 4022 rights. 4024 Disclaimer of Validity 4026 This document and the information contained herein are provided on an 4027 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 4028 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 4029 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 4030 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 4031 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 4032 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 4034 Copyright Statement 4036 Copyright (C) The Internet Society (2005). This document is subject 4037 to the rights, licenses and restrictions contained in BCP 78, and 4038 except as set forth therein, the authors retain all their rights. 4040 Acknowledgment 4042 Funding for the RFC Editor function is currently provided by the 4043 Internet Society.