idnits 2.17.1 draft-ietf-forces-protocol-03.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 3974. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3946. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3953. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3959. ** 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 648: '... ForCES transactions MUST support ACIDity [ACID], defined as:...' RFC 2119 keyword, line 668: '...or more messages MUST have ACID proper...' RFC 2119 keyword, line 706: '... records of the transaction MUST reply...' RFC 2119 keyword, line 935: '... field. Senders SHOULD set it to zero...' RFC 2119 keyword, line 1032: '...tive, a particular multicast ID MAY be...' (14 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 1275 has weird spacing: '...nt with the i...' == Line 1327 has weird spacing: '...is used with ...' == Line 2187 has weird spacing: '...data is a 'PA...' == Line 2348 has weird spacing: '...data is a 'PA...' == (2 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 (June 7, 2005) is 6897 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 1149, but not defined == Missing Reference: 'SELECTOR' is mentioned on line 1150, but not defined == Missing Reference: 'TBD' is mentioned on line 2457, but not defined -- Looks like a reference, but probably isn't: '101' on line 3077 -- Looks like a reference, but probably isn't: '200' on line 3077 == Unused Reference: 'RFC2629' is defined on line 2887, 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 (~~), 13 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: December 9, 2005 June 7, 2005 6 ForCES Protocol Specification 7 draft-ietf-forces-protocol-03.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 December 9, 2005. 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 . . . . . . . . . . . . . . . . . . . . . . 20 72 4.1 TML Parameterization . . . . . . . . . . . . . . . . . . 21 73 5. Message encapsulation . . . . . . . . . . . . . . . . . . . 22 74 5.1 Common Header . . . . . . . . . . . . . . . . . . . . . 22 75 5.2 Type Length Value . . . . . . . . . . . . . . . . . . . 25 76 5.2.1 Nested TLVs . . . . . . . . . . . . . . . . . . . . 26 77 5.2.2 Scope of the T in TLV . . . . . . . . . . . . . . . 26 78 6. Protocol Construction . . . . . . . . . . . . . . . . . . . 27 79 6.1 Protocol Grammar . . . . . . . . . . . . . . . . . . . . 27 80 6.1.1 Protocol BNF . . . . . . . . . . . . . . . . . . . . 27 81 6.1.2 Protocol Visualization . . . . . . . . . . . . . . . 31 82 6.2 Core ForCES LFBs . . . . . . . . . . . . . . . . . . . . 34 83 6.2.1 FE Protocol LFB . . . . . . . . . . . . . . . . . . 35 84 6.2.2 FE Object LFB . . . . . . . . . . . . . . . . . . . 36 85 6.2.3 CE LFB . . . . . . . . . . . . . . . . . . . . . . . 37 86 6.3 Semantics of message Direction . . . . . . . . . . . . . 38 87 6.4 Association Messages . . . . . . . . . . . . . . . . . . 38 88 6.4.1 Association Setup Message . . . . . . . . . . . . . 38 89 6.4.2 Association Setup Response Message . . . . . . . . . 40 90 6.4.3 Association Teardown Message . . . . . . . . . . . . 42 91 6.5 Configuration Messages . . . . . . . . . . . . . . . . . 44 92 6.5.1 Config Message . . . . . . . . . . . . . . . . . . . 44 93 6.5.2 Config Response Message . . . . . . . . . . . . . . 46 94 6.6 Query and Query Response Messages . . . . . . . . . . . 48 95 6.6.1 Query Message . . . . . . . . . . . . . . . . . . . 48 96 6.6.2 Query Response Message . . . . . . . . . . . . . . . 50 97 6.7 Event Notification and Response Messages . . . . . . . . 51 98 6.7.1 Event Notification Message . . . . . . . . . . . . . 52 99 6.7.2 Event Notification Response Message . . . . . . . . 54 100 6.8 Packet Redirect Message . . . . . . . . . . . . . . . . 55 101 6.9 Heartbeat Message . . . . . . . . . . . . . . . . . . . 57 102 6.10 Operation Summary . . . . . . . . . . . . . . . . . . . 58 103 7. Protocol Scenarios . . . . . . . . . . . . . . . . . . . . . 60 104 7.1 Association Setup state . . . . . . . . . . . . . . . . 60 105 7.2 Association Established state or Steady State . . . . . 61 106 8. High Availability Support . . . . . . . . . . . . . . . . . 64 107 8.1 Responsibilities for HA . . . . . . . . . . . . . . . . 66 108 9. Security Considerations . . . . . . . . . . . . . . . . . . 68 109 9.1 No Security . . . . . . . . . . . . . . . . . . . . . . 68 110 9.1.1 Endpoint Authentication . . . . . . . . . . . . . . 68 111 9.1.2 Message authentication . . . . . . . . . . . . . . . 69 112 9.2 ForCES PL and TML security service . . . . . . . . . . . 69 113 9.2.1 Endpoint authentication service . . . . . . . . . . 69 114 9.2.2 Message authentication service . . . . . . . . . . . 69 115 9.2.3 Confidentiality service . . . . . . . . . . . . . . 70 116 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . 71 117 11. References . . . . . . . . . . . . . . . . . . . . . . . . 72 118 11.1 Normative References . . . . . . . . . . . . . . . . . . 72 119 11.2 Informational References . . . . . . . . . . . . . . . . 72 120 Author's Address . . . . . . . . . . . . . . . . . . . . . . 72 121 A. Individual Authors/Editors Contact . . . . . . . . . . . . . 73 122 B. IANA considerations . . . . . . . . . . . . . . . . . . . . 75 123 C. Forces Protocol LFB schema . . . . . . . . . . . . . . . . . 76 124 C.1 Events . . . . . . . . . . . . . . . . . . . . . . . . . 77 125 C.2 Capabilities . . . . . . . . . . . . . . . . . . . . . . 77 126 C.3 Attributes . . . . . . . . . . . . . . . . . . . . . . . 77 127 C.3.1 HBI . . . . . . . . . . . . . . . . . . . . . . . . 77 128 C.3.2 HBDI . . . . . . . . . . . . . . . . . . . . . . . . 78 129 C.3.3 CurrentRunningVersion . . . . . . . . . . . . . . . 78 130 D. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . 79 131 E. Implementation Notes . . . . . . . . . . . . . . . . . . . . 95 132 E.1 TML considerations . . . . . . . . . . . . . . . . . . . 95 133 E.1.1 PL Flag inference by TML . . . . . . . . . . . . . . 95 134 E.1.2 Message type inference to Mapping at the TML . . . . 96 135 F. changes between -02 and -03 . . . . . . . . . . . . . . . . 98 136 G. Changes between -01 and -02 . . . . . . . . . . . . . . . . 99 137 H. Changes between -00 and -01 . . . . . . . . . . . . . . . . 100 138 Intellectual Property and Copyright Statements . . . . . . . 101 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 packet processing 246 operation in the datapath. LFB types are the basic building blocks 247 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 in Section 3.3.1.2. 617 3.3.1.1 Execution 619 There are two schools of thoughts which are being tossed around at 620 the moment on Forces operations from the CE to the FE. We try to 621 support both and leave the details to implementation (the 622 intelligence is at the CE). 624 1. The CE knows exact details about the resources at the FE (memory, 625 table sizes, etc). When it says "SET" it knows that would work 626 etc. In this scenario, it is contended by the proponents of this 627 optimization that when a CE decides to send a command to an FE it 628 will work 100%. In other words, remote operations without any 629 transactional properties (given the CE computes the success of 630 the tranaaction). 632 2. The classical Two-phase-commit(2PC)[REference to be added here] 633 scheme; undo/rollback when things go wrong. undoing is initiated 634 by the CE after an error response from any one FE being 635 synchronized is received. 637 There are 3 execution modes that could be requested for operations 638 spanning on one or more LFB selectors: 640 Transactional all-or-none. 642 Any-of-N independent operations. 644 go-to-N loose transaction. 646 3.3.1.1.1 Requirements for ForCES Transactions 648 ForCES transactions MUST support ACIDity [ACID], defined as: 650 o *Atomicity*. In a transaction involving two or more discrete 651 pieces of information, either all of the pieces are committed or 652 none are. 654 o *Consistency*. A transaction either creates a new and valid state 655 of data, or, if any failure occurs, returns all data to its state 656 before the transaction was started. 658 o *Isolation*. A transaction in process and not yet committed must 659 remain isolated from any other transaction. 661 o *Durability*. Committed data is saved by the system such that, 662 even in the event of a failure and system restart, the data is 663 available in its correct state. 665 3.3.1.1.1.1 Transaction definition 667 We define a transaction as a collection of one or more ForCES 668 operations within one or more messages MUST have ACID properties. 670 3.3.1.1.1.2 Transaction protocol 672 A 2PC starts with a START | ATOMIC flag on its first message of a 673 transaction. A transaction may span multiple messages. It is up to 674 the CE to keep track of the different seq #s making up a transaction. 675 This may then be followed by more messages which are part of the same 676 atomic transaction. 678 Any failure notified by the FE causes the CE to execute an ABORT to 679 all FEs involved in the transaction, rolling back all previously 680 executed operations in the transaction. 682 The transaction commitment phase is signalled by an empty DONE msg 683 type. 685 TBD: We may need an ABORT message(used for rollback purposes) or 686 maybe a DONE with an ABORT flag to undo will suffice. 688 3.3.1.1.1.3 Recovery 690 Any of the participating FEs, or the CE, or the associations between 691 them, may fail after the DONE message has left the CE and before it 692 has received all the responses, (possibly the DONE never reached the 693 FEs). At this point it is known that none of the operations failed 694 but it is presumed that the data has not yet been made durable by the 695 FEs. The means of detecting such failures may include loss of 696 heartbeat (within the scope of ForCES) or mechanisms outside the 697 scope of ForCES. When the associations are re-established, the CE 698 will discover a transaction in an intermediate state. Some FEs will 699 have made the data durable and closed the transaction; others may 700 have failed while doing so, and may, or may not, still have that 701 data. At this point the transaction enters the recovery phase. 703 The CE re-issues an empty DONE message to all FEs involved in the 704 transaction. Those that completed the transaction confirm this to 705 the CE. Those that did not, commit the data and confirm this to the 706 CE. An FE that has lost all records of the transaction MUST reply 707 with status UNKNOWN and the actions subsequently taken by the CE are 708 implementation dependent. 710 This requires knowledge at both the CE and FE; not sure how to signal 711 it. Global flags: ATOMIC, START, ABORT? (used by 2PC) New msg type: 712 DONE, ABORT?(used by 2PC) 714 3.3.1.1.2 one-of-N independent operations 716 In which several independent operations are targeted at one or more 717 LFB selectors. Execution continues at the FE when one or more 718 operations fail. This mode is signalled by a missing ATOMIC flag. 720 3.3.1.1.3 go-to-N loose transaction 722 In which all operations are executed on FE sequentially until first 723 failure. The rest of the operations are not executed but everything 724 upto failed is not undone unlike #1. flag: GOTON (global) 726 3.3.1.1.4 Relation to Multipart messages 728 Multipart flags apply. I.e all messages in a transaction except 729 for the last have a MULTIPART flag on. 731 There has to be consistency across the multi parts of the 732 messages. In other words the first message starting with mode #1 733 above, implies the rest do. Any inconsitency implies a cancelled 734 transaction in which all messages are dropped and the sender 735 NACKED. 737 3.3.1.2 Response formating 739 TBD - ISSUE 22 741 3.3.2 FE, CE, and FE protocol LFBs 743 All PL messages follow the LFB structure as this provides more 744 flexibility for future enhancements. This means maintanance and 745 configurability of FEs, NE, as well as the protocol require a fit in 746 the LFB architecture. For this reason special LFBs are created to 747 accomodate this need. 749 In addition, this shows how the ForCES protocol itself can be 750 controlled by the very same type of structures (LFBs) it uses to 751 control functions such as IP forwarding, filtering, etc. 753 To achieve this, the following LFBs are used: 755 o FE Protocol LFB 757 o FE LFB 759 o CE LFB 761 These LFBs are detailed in Section 6.2. A short description is 762 provided here: 764 o The FE Protocol LFB is a logical entity in each FE that is used to 765 control the ForCES protocol. The CE operates on this LFB to 766 subscribe or unsubscribe to Heartbeat messages, define the 767 Heartbeat interval, or to discover which ForCES protocol version 768 is supported and which TMLs the FE supports. The FE Protocol LFB 769 also contains the various ForCES ID to be used: unicast IDs a 770 table of the PL multicast IDs the FE must be listening to. [TBD: 771 do we need a CE Protocol LFB?] 773 o The FE LFB (referred to as "FE attributes" in the model draft) 774 should not be confused with the FE Protocol Object. The FE LFB is 775 a logical entity in each FE and contains attributes relative to 776 the FE itself, and not to the operation of the ForCES protocol 777 between the CE and the FE. Such attributes can be FEState (refer 778 to model draft), vendor, etc. The FE LFB contains in particular a 779 table that maps a virtual LFB Instance ID to one or more Instance 780 IDs of LFBs in the FE. 782 o The CE LFB is the counterpart of the FE LFB. The CE LFB is a 783 logical entity in each CE and contains attributes relative to the 784 CE itself, and not to the operation of the ForCES protocol between 785 the CE and the FE. This LFB can be used to convey event 786 notifications from a CE to FEs. Some events may be sent by the CE 787 without prior subscription by the FEs. 789 3.3.3 Scaling by Concurrency 791 It is desirable that the PL layer not become the bottleneck when 792 larger bandwidth pipes become available. To pick a mythical example 793 in today's terms, if a 100Gbps pipe is available and there is 794 sufficient work then the PL layer should be able to take advantage of 795 this and use all of the 100Gbps pipe. Two mechanisms are provided to 796 achieve this. The first one is batching and the second one is a 797 command window. 799 Batching is the ability to send multiple commands (such as Config) in 800 one PDU. The size of the batch will be affected by, amongst other 801 things, the path MTU. The commands may be part of the same 802 transaction or part of unrelated transactions that are independent of 803 each other. 805 Command windowing allows for pipelining of independent transactions 806 which do not affect each other. Each independent transaction could 807 consist of one or more batches. 809 3.3.3.1 Batching 811 There are several batching levels at different protocol hierarchies. 813 o multiple PL PDUs can be aggregated under one TML message 815 o multiple LFB classes and instances can be addressed within one PL 816 PDU 818 o Multiple operations can be addressed to a single LFB class and 819 instance 821 3.3.3.2 Command Pipelining 823 TBD - ISSUE 33 825 4. TML Requirements 827 The requirements below are expected to be delivered by the TML. This 828 text does not define how such mechanisms are delivered. As an 829 example they could be defined to be delivered via hardware or inter- 830 TML protocol level schemes. 832 Each TML must describe how it contributes to achieving the listed 833 ForCES requirements. If for any reason a TML does not provide a 834 service listed below a justification needs to be provided. 836 1. Reliability 837 As defined by RFC 3654, section 6 #6. 839 2. Security 840 TML provides security services to the ForCES PL. TML layer 841 should support the following security services and describe how 842 they are achieved. 844 * Endpoint authentication of FE and CE. 846 * Message Authentication 848 * Confidentiality service 850 3. Congestion Control 851 The congestion control scheme used needs to be defined. 852 Additionally, the circumstances under which notification is sent 853 to the PL to notify it of congestion must be defined. 855 4. Uni/multi/broadcast addressing/delivery if any 856 If there is any mapping between PL and TML level Uni/Multi/ 857 Broadcast addressing it needs to be defined. 859 5. Timeliness 861 6. TBD - ISSUE 21 863 7. HA decisions 864 It is expected that availability of transport links is the TML's 865 responsibility. However, on config basis, the PL layer may wish 866 to participate in link failover schemes and therefore the TML 867 must support this capability. 868 Please refer to the HA Section Section 8 for details. 870 8. Encapsulations used. 871 Different types of TMLs will encapsulate the PL messages on 872 different types of headers. The TML needs to specify the 873 encapsulation used. 875 9. Prioritization 876 It is expected that the TML will be able to handle up to 8 877 priority levels needed by the PL layer and will provide 878 preferential treatment. 879 TML needs to define how this is achieved. 881 10. Protection against DoS attacks 882 As described in the Requirements RFC 3654, section 6 884 4.1 TML Parameterization 886 It is expected that it should be possible to use a configuration 887 reference point, such as the FEM or the CEM, to configure the TML. 889 Some of the configured parameters may include: 891 o PL ID 893 o Connection Type and associated data. For example if a TML uses 894 IP/TCP/UDP then parameters such as TCP and UDP ports, IP addresses 895 need to be configured. 897 o Number of transport connections 899 o Connection Capability, such as bandwidth, etc. 901 o Allowed/Supported Connection QoS policy (or Congestion Control 902 Policy) 904 5. Message encapsulation 906 All PL layer PDUs start with a common header [Section 5.1] followed 907 by a one or more TLVs [Section 5.2] which may nest other TLVs 908 [Section 5.2.1]. 910 5.1 Common Header 912 0 1 2 3 913 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 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 915 |version| rsvd | Message Type | Length | 916 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 917 | Source ID | 918 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 919 | Destination ID | 920 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 921 | Sequence Number | 922 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 923 | Flags | 924 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 926 Figure 6: Common Header 928 The message is 32 bit aligned. 930 Version (4 bit): 931 Version number. Current version is 1. 933 rsvd (4 bit): 934 Unused at this point. A receiver should not interpret this 935 field. Senders SHOULD set it to zero. 937 Message Type (8 bits): 938 Commands are defined in Section 6. 940 Source ID (32 bit): 942 Dest ID (32 bit): 944 * Each of the source and Dest IDs are 32 bit IDs which 945 recognize the termination points. Ideas discussed so far are 946 desire to recognize if ID belongs to FE or CE by inspection. 947 Suggestions for achieving this involves partitioning of the 948 ID allocation. Another alternative maybe to use flags to 949 indicate direction (this avoids partition). 951 * IDs will allow multi/broad/unicast 953 * Addressing 955 a. As ForCES may run between multiple CEs and FEs and over 956 different protocols such as IPv4 and IPv6, or directly 957 over Ethernet or other switching-fabric interconnects, it 958 is necessary to create an addressing scheme for ForCES 959 entities. Mappings to the underlying TML-level 960 addressing can then be defined as appropriate. 962 b. Fundamentally, unique IDs are assigned to CEs and FEs. A 963 split address space is used to distinguish FEs from CEs. 964 Even though we can assume that in a large NE there are 965 typically two or more orders of magnitude more FEs than 966 CEs, the address space is split uniformly for simplicity. 968 c. Special IDs are reserved for FE broadcast, CE broadcast, 969 and NE broadcast. 971 d. Subgroups of FEs belonging, for instance, to the same 972 VPN, may be assigned a multicast ID. Likewise, subgroups 973 of CEs that act, for instance, in a back-up mode may be 974 assigned a multicast ID. These FEs and CE multicast IDs 975 are chosen in a distinct portion of the ID address space. 976 Such a multicast ID may comprise FEs, CEs, or a mix of 977 both. 979 e. As a result, the address space allows up to 2^30 (over a 980 billion) CEs and the same amount of FEs. 982 0 1 2 3 983 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 984 0 1 2 3 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 986 |TS | sub-ID | 987 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 989 Figure 7: ForCES ID Format 991 f. The ForCES ID is 32 bits. The 2 most significant bits 992 called Type Switch (TS) are used to split the ID space as 993 follows: 995 A. TS Corresponding ID range Assignment 997 B. -- ---------------------- ---------- 998 C. 0b00 0x00000000 to 0x3FFFFFFF FE IDs (2^30) 1000 D. 0b01 0x40000000 to 0x7FFFFFFF CE IDs (2^30) 1002 E. 0b10 0x80000000 to 0xBFFFFFFF reserved 1004 F. 0b11 0xC0000000 to 0xFFFFFFEF multicast IDs 1005 (2^30 - 16) 1007 G. 0b11 0xFFFFFFF0 to 0xFFFFFFFC reserved 1009 H. 0b11 0xFFFFFFFD all CEs broadcast 1011 I. 0b11 0xFFFFFFFE all FEs broadcast 1013 J. 0b11 0xFFFFFFFF all FEs and CEs 1014 (NE) broadcast 1016 g. It is desirable to address multicast and/or broadcast 1017 messages to some LFB instances of a given class. For 1018 instance, assume FEs FEa and FEb: 1020 - FEa has LFBs LFBaX1 and LFBaX2 of class X 1022 - similarly, FEb has two LFBs LFBbX1 and LFBbX2 of 1023 class X. 1025 A broadcast message should be addressable to only LFBs 1026 LFBaX1 and LFBbX1 (this can be the case for instance if 1027 these two LFBs belong to the same VPN). To achieve this, 1028 a VPN ID (3 octets OUI and 4 octets VPN Index) as defined 1029 in RFC 2685 should be used within the ForCES message body 1030 as a TLV. 1032 As an alternative, a particular multicast ID MAY be 1033 associated to a given VPN ID through some configuration 1034 means. Messages delivered to such a multicast ID MUST 1035 only be applied to LFBs belonging to that VPN ID. 1037 Sequence (32 bits) 1038 Unique to a PDU. [Discussion: There may be impact on the effect 1039 of subsequence numbers]. 1041 Length (16 bits): 1042 length of header + the rest of the message in DWORDS (4 byte 1043 increments). 1045 Flags(32 bits): 1046 Identified so far: 1048 - ACK indicator(2 bit) 1049 The description for using the two bits is: 1051 'NoACK' (00) 1053 'SuccessACK'(01) 1055 'UnsuccessACK'(10) 1057 'ACKAll' (11) 1059 - Priority (3 bits) 1060 TBD 1062 - Throttle flag 1064 - Batch (2 bits) 1066 - Atomicity (1 or more bits. TBD) 1068 5.2 Type Length Value 1069 0 1 2 3 1070 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 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 | TLV Type | variable TLV Length | 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 | Value (Data of size TLV length) | 1075 ~ ~ 1076 ~ ~ 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1079 TLV Type: 1081 The TLV type field is two octets, and indicates the type of data 1082 encapsulated within the TLV. 1084 TLV Length: 1086 The TLV Length field is two octets, and indicates the length of 1087 this TLV including the TLV Type, TLV Length, and the TLV data. 1089 TLV Value: 1091 The TLV Value field carries the data. For extensibility, the TLV 1092 Value may be a TLV. In fact, this is the case with the 1093 Netlink2-extension TLV. The Value encapsulated within a TLV is 1094 dependent of the attribute being configured and is opaque to 1095 Netlink2 and therefore is not restricted to any particular type 1096 (example could be ascii strings such as XML, or OIDs etc). 1098 TLVs must be 32 bit aligned. 1100 Figure 8: TLV 1102 5.2.1 Nested TLVs 1104 TLV values can be other TLVs. This provides the benefits of protocol 1105 flexibility (being able to add new extensions by introducing new TLVs 1106 when needed). The nesting feature also allows easy mapping between 1107 the XML LFB definitions to binary PL representation. 1109 5.2.2 Scope of the T in TLV 1111 The "Type" value in TLV is of global scope. This means that wherever 1112 in the PDU hierachy a Type has global connotations. This is a design 1113 choice to ease debugging of the protocol. 1115 6. Protocol Construction 1117 6.1 Protocol Grammar 1119 The protocol construction is formally defined using a BNF-like syntax 1120 to describe the structure of the PDU layout. This is matched to a 1121 precise binary format later in the document. 1123 Since the protocol is very flexible and hierachical in nature, it is 1124 easier at times to see the visualization layout. This is provided in 1125 Section 6.1.2 1127 6.1.1 Protocol BNF 1129 The format used is based on RFC 2234. The terminals of this gramar 1130 are flags, IDcount, IDs, KEYID, KEY_DATA and DATARAW, described after 1131 the grammar. 1133 1. A TLV will have the word "TLV" at the end of its name 1135 2. / is used to separate alternatives 1137 3. parenthesised elements are treated as a single item 1139 4. * before an item indicates 0 or more repetitions 1* before an 1140 item indicates 1 or more repetitions 1142 5. [] around an item indicates that it is optional (equal to *1) 1144 The BNF of the PL level PDU is as follows: 1146 PL level PDU := MAINHDR 1*LFBselect-TLV 1147 LFBselec-TLV := LFBCLASSID LFBInstance 1*OPER-TLV 1148 OPER-TLV := 1*PATH-DATA-TLV 1149 PATH-DATA-TLV := PATH [DATA] 1150 PATH := flags IDcount IDs [SELECTOR] 1151 SELECTOR := KEYINFO-TLV 1152 DATA := DATARAW-TLV / RESULT-TLV / 1*PATH-DATA-TLV 1153 KEYINFO-TLV := KEYID KEY_DATA 1154 DATARAW-TLV := encoded data which may nest DATARAW TLVs 1155 RESULT-TLV := not yet defined. 1156 Holding result code and optional DATARAW 1158 o MAINHDR defines a message type, Target FE/CE ID etc. The MAINHDR 1159 also defines the content. As an example the content of a "config" 1160 message would be different from an "association" message. 1162 o LFBCLASSID is a 32 bit unique identifier per LFB class defined at 1163 class Definition time. 1165 o LFBInstance is a 32 bit unique instance identifier of an LFB class 1167 o OPERATION is one of {ADD,DEL,etc.} depending on the message type 1169 o PATH-DATA-TLV identifies the exact element targeted. It may have 1170 zero or more paths associated with it terminated by zero or more 1171 data values associated. 1173 o PATH provides the path to the data being referenced. 1175 * flags (16 bits) are used to further refine the operation to be 1176 applied on the Path. More on these later. 1178 * IDcount(16 bit): count of 32 bit IDs 1180 * IDs: zero or more 32bit IDs (whose count is given by IDcount) 1181 defining the main path. Depending on the flags, IDs could be 1182 field IDs only or a mix of field and dynamic IDs. Zero is used 1183 for the special case of using the entirety of the containing 1184 context as the result of the path. 1186 o SELECTOR is an optional construct that further defines the PATH. 1187 Currently, the only defined selector is the KEYINFO-TLV, used for 1188 selecting an array entry by the value of a key field. The 1189 presence of a SELECTOR is correct only when the flags also 1190 indicate its presence. A mismatch is a protocol format error. 1192 o A KEYINFO TLV contains information used in content keying. 1194 * A KeyID is used in a KEYINFO TLV. It indicates which key for 1195 the current array is being used as the content key for array 1196 entry selection. 1198 * KEY_DATA is the data to look for in the array, in the fields 1199 identified by the keyfield. The information is encoded 1200 according to the rules for the contents of a DATARAW, and 1201 represent the field or fields which make up the key identified 1202 by the KEYID. 1204 o DATA may contain a DATARAW or 1 or more further PATH-DATA 1205 selection DATARAW is only allowed on SET requests, or on responses 1206 which return content information (GET Response for example.) 1207 PATH-DATA may be included to extent the path on any request. 1209 * Note: Nested PATH-DATA TLVs are supported as an efficiency 1210 measure to permit common subexpression extraction. 1212 * DATARAW contains "the data" whose path is selected. 1214 o RESULT contains the indication of whether the individual SET 1215 succeeded. If there is an indication for verbose response, then 1216 SETRESULT will also contain the DATARAW showing the data that was 1217 set. RESULT-TLV is included on the assumption that individual 1218 parts of a SET request can succeed or fail separately. 1220 In summary this approach has the following characteristic: 1222 o There can be one or more LFB Class + InstanceId combo targeted in 1223 a message (batch) 1225 o There can one or more operations on an addressed LFB classid+ 1226 instanceid combo(batch) 1228 o There can be one or more path targets per operation (batch) 1230 o Paths may have zero or more data values associated (flexibility 1231 and operation specific) 1233 It should be noted that the above is optimized for the case of a 1234 single classid+instance targeting. To target multiple instances 1235 within the same class, multiple LFBselect are needed. 1237 6.1.1.1 Discussion on Grammar 1239 Data is packed in such a way that a receiver of such data with 1240 knowledge of the path can correlate what it means by infering in the 1241 LFB definition. This is an optimization that helps reducing the 1242 amount of description for the data in the protocol. 1244 In other words: 1246 It is assumed that the type of the data can be inferred by the 1247 context in which data is used. Hence, data will not include its type 1248 information. The basis for the inference is typically the LFB class 1249 id and the path. 1251 6.1.1.1.1 Data Packing Rules 1253 The scheme for packaging data used in this doc adheres to the 1254 following rules: 1256 o The Value of DATARAW TLV will contain the data being transported. 1257 This data will be as was described in the LFB definition. 1259 o By definition in the Forces protocol, all TLVs are 32 bit aligned. 1260 Therefore because DATARAW is a TLV, elements not aligned in 32 bit 1261 values will be padded. 1263 o As an example a 16 bit value will have an extra 16 bit pad; 1264 however two 16 bits values in a structure will be shipped together 1265 with no padding etc. 1267 o Variable sized data will be encapsulated inside another DATARAW 1268 TLV inside the V of the outer TLV. For example of this see 1269 Appendix D example 13. 1271 o When a table is refered in the PATH (ids), then the RAWDATA's V 1272 will contain that tables row content prefixed by its 32 bit index/ 1273 subscript OTOH, when SELECTOR flags are 00, the PATH may contain 1274 an index pointing to a row in table; in such a case, the RAWDATA's 1275 V will only contain the content with the index in order to avoid 1276 ambiguity. 1278 6.1.1.1.2 Path Flags 1280 The following flags are currently defined: 1282 o SELECTOR Bit: F_SELKEY indicates that a KEY Selector is present 1283 following this path information, and should be considered in 1284 evaluating the path. 1286 o FIND-EMPTY Bit: This must not be set if the F_SEL_KEY bit is set. 1287 This must only be used on a create operation. If set, this 1288 indicates that although the path identifies an array, the SET 1289 operation should be applied to the first unused element in the 1290 array. The result of the operation will not have this flag set, 1291 and will have the assigned index in the path. 1293 6.1.1.1.3 Relation of operational flags with global message flags 1295 Should be noted that other applicable flags such as atomicity 1296 indicators as well as verbosity result formaters are in the main 1297 headers flags area. 1299 6.1.1.1.4 Content Path Selection 1301 The KEYINFO TLV describes the KEY as well as associated KEY data. 1303 KEYs, used for content searches, are restricted and described in the 1304 LFB definition. 1306 6.1.1.1.5 Operation TLVs 1308 It is assumed that specific operations are identified by the type 1309 code of the TLV. And that response are also identified by specific 1310 TLV opcodes 1312 6.1.1.1.6 SET and GET Relationship 1314 It is expected that a GET-RESPONSE would satisfy the following 1315 desires: 1317 o it would have exactly the same path definitions as that was sent 1318 in the GET. The only difference being a GET-RESPONSE will contain 1319 DATARAW TLVs. 1321 o it should be possible that one would take the same GET-RESPONSE 1322 and convert it to a SET-REPLACE successfully by merely changing 1323 the T in the operational TLV. 1325 o There are exceptions to this rule: 1327 1. When a KEY selector is used with a path in a GET operation, 1328 that selector is not returned in the GET-RESPONSE; instead the 1329 cooked result is returned. Refer to the examples using KEYS 1330 to see this. 1332 2. When dumping a whole table in a GET, the GET-RESPONSE, merely 1333 editing the T to be SET will endup overwritting the table. 1335 6.1.2 Protocol Visualization 1337 The figure below shows a general layout of the PL PDU. A main header 1338 is followed by one or more LFB selections each of which may contain 1339 one or more operation. 1341 main hdr (Config in this case) 1342 | 1343 | 1344 +--- T = LFBselect 1345 | | 1346 | +-- LFBCLASSID 1347 | | 1348 | | 1349 | +-- LFBInstance 1350 | | 1351 | +-- T = SET-CREATE 1352 | | | 1353 | | +-- // one or more path targets 1354 | | // with their data here to be added 1355 | | 1356 | +-- T = DEL 1357 | . | 1358 | . +-- // one or more path targets to be deleted 1359 | 1360 | 1361 +--- T = LFBselect 1362 | | 1363 | +-- LFBCLASSID 1364 | | 1365 | | 1366 | +-- LFBInstance 1367 | | 1368 | + -- T= SET-REPLACE 1369 | | 1370 | | 1371 | + -- T= DEL 1372 | | 1373 | + -- T= SET-REPLACE 1374 | 1375 | 1376 +--- T = LFBselect 1377 | 1378 +-- LFBCLASSID 1379 | 1380 +-- LFBInstance 1381 . 1382 . 1383 . 1385 Figure 10: PL PDU layout 1387 The figure below shows an example general layout of the operation 1388 within a targetted LFB selection. The idea is to show the different 1389 nesting levels a path could take to get to the target path. 1391 T = SET-CREATE 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 | | 1405 | +- T = Path-data 1406 | | 1407 | + -- flags 1408 | + -- IDCount 1409 | + -- IDs 1410 | + -- T = KEYINFO 1411 | | + -- KEY_ID 1412 | | + -- KEY_DATA 1413 | | 1414 | + -- T = DATARAW 1415 | + -- data 1416 | 1417 | 1418 T = SET-REPLACE 1419 | | 1420 | +- T = Path-data 1421 | | | 1422 | | + -- flags 1423 | | + -- IDCount 1424 | | + -- IDs 1425 | | | 1426 | | + -- T = DATARAW 1427 | | + -- data 1428 | +- T = Path-data 1429 | | 1430 | + -- flags 1431 | + -- IDCount 1432 | + -- IDs 1433 | | 1434 | + -- T = DATARAW 1435 | + -- data 1436 T = DEL 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 | 1450 +- T = Path-data 1451 | 1452 + -- flags 1453 + -- IDCount 1454 + -- IDs 1455 + -- T = KEYINFO 1456 | + -- KEY_ID 1457 | + -- KEY_DATA 1458 +- T = Path-data 1459 | 1460 + -- flags 1461 + -- IDCount 1462 + -- IDs 1464 Figure 11: Sample operation layout 1466 6.2 Core ForCES LFBs 1468 There are three LFBs that are used to control the operation of the 1469 ForCES protocol and to interact with FEs and CEs: 1471 FE protocol LFB 1473 FE LFB 1475 CE LFB 1477 Although these LFBs have the same form and interface as other LFBs, 1478 they are special in many respects: they have fixed well-known LFB 1479 Class and Instance IDs. They are statically defined (no dynamic 1480 instantiation allowed) and their status cannot be changed by the 1481 protocol: any operation to change the state of such LFBs (for 1482 instance, in order to disable the LFB) must result in an error. 1483 Moreover, these LFBs must exist before the first ForCES message can 1484 be sent or received. All attributes in these LFBs must have pre- 1485 defined default values. Finally, these LFBs do not have input or 1486 output ports and do not integrate into the intra-FE LFB topology. 1488 6.2.1 FE Protocol LFB 1490 The FE Protocol LFB is a logical entity in each FE that is used to 1491 control the ForCES protocol. The FE Protocol LFB Class ID is 1492 assigned the value 0x1. The FE LFB Instance ID is assigned the value 1493 0x1. There must always be one and only one instance of the FE 1494 Protocol LFB in an FE. The values of the attributes in the FE 1495 Protocol LFB have pre-defined default values that are specified here. 1496 Unless explicit changes are made to these values using Config 1497 messages from the CE, these default values MUST be used for the 1498 operation of the protocol. 1500 The formal definition of the FE Protocol LFB can be found in 1501 Appendix C 1503 The FE Protocol LFB consists of the following elements: 1505 o FE Protocol events that can be subscribed/unsubscribed: 1507 * FE heartbeat 1509 * FE TML events (TBD) 1511 o FE Protocol capabilities (read-only): 1513 * Supported ForCES protocol version(s) by the FE 1515 * Supported ForCES FE model(s) by the FE 1517 * Some TML capability description(s) 1519 o FE Protocol attributes (can be read and set): 1521 * Current version of the ForCES protocol 1523 * Current version of the FE model 1524 * FE unicast ID 1526 * FE multicast ID(s) (list) 1528 * Association Expiry Timer 1530 * Heartbeat Interval 1532 * Primary CE 1534 * FE failover and restart policy 1536 * CE failover and restart policy 1538 6.2.2 FE Object LFB 1540 The FE Object LFB is a logical entity in each FE and contains 1541 attributes relative to the FE itself, and not to the operation of the 1542 ForCES protocol. The FE LFB Class ID is assigned the value 0x2. The 1543 FE LFB Instance ID is assigned the value 0x1. There must always be 1544 one and only one instance of the FE LFB in an FE. 1546 The formal definition of the FE Object LFB can be found in [FE-MODEL] 1548 The FE LFB consists of the following elements: 1550 FE Events: 1552 * FEAllEvents: subscribing to this corresponds to subscribing to 1553 all events below 1555 * FEStatusChange: events that signal FE Status: 1557 + Up 1559 + Down 1561 + Active 1563 + Inactive 1565 + Failover 1567 * FE DoS alert 1569 * FE capability change 1570 FE attributes: 1572 * FEStatus: to set the FE mode as: 1574 + Active 1576 + Inactive 1578 + Shutdown 1580 * FELFBInstancelist 1582 * FENeighborList 1584 * MIID table: a list of virtual LFB Instance IDs that map to a 1585 list of Instance IDs of LFBs in that FE 1587 * FE Behavior Exp. Timer 1589 * HA Mode 1591 * FE DoS protection policy 1593 * FEPrivateData: Proprietary info such as name, vendor, model. 1595 * Inter-FE topology Intra-FE topology 1597 6.2.3 CE LFB 1599 The CE LFB is a logical entity in each CE and contains attributes 1600 relative to the CE itself, and not to the operation of the ForCES 1601 protocol. 1603 The CE LFB consists of the following elements: 1605 CE Events: 1607 * CEAllEvents: subscribing to this corresponds to subscribing to 1608 all events listed below. 1610 * CEStatusChange: events that signal CE Up/Down/Active/Inactive/ 1611 Failover. 1613 Note: Such events do not necessarily need to be subscribed to, 1614 they can fire even without subscription and be sent to 1615 the FE 1617 6.3 Semantics of message Direction 1619 Recall: The PL protocol provides a master(CE)-Slave(FE) relationship. 1620 The LFBs reside at the FE and are controlled by CE. 1622 When messages go from the CE, the LFB Selector (Class and instance) 1623 refers to the destination LFB selection which resides in the FE. 1625 When messages go from the FE->CE, the LFB Selector (Class and 1626 instance) refers to the source LFB selection which resides in the FE. 1628 6.4 Association Messages 1630 The ForCES Association messages are used to establish and teardown 1631 associations between FEs and CEs. 1633 6.4.1 Association Setup Message 1635 This message is sent by the FE to the CE to setup a ForCES 1636 association between them. This message could also be used by CEs to 1637 join a ForCES NE, however CE-to-CE communication is not covered by 1638 this protocol. 1640 Message transfer direction: 1641 FE to CE 1643 Message Header: 1644 The Message Type in the header is set MessageType= 'Association 1645 Setup'. The ACK flag in the header is ignored, because the setup 1646 message will always expect to get a response from the message 1647 receiver (CE) whether the setup is successful or not. The Src ID 1648 (FE ID) may be set to O in the header which means that the FE 1649 would like the CE to assign a FE ID for the FE in the setup 1650 response message. 1652 Message body: 1653 The LFB selection points to the FE Object and more than one FE 1654 Object attribute may be announced in this message. The layout 1655 looks like: 1657 main hdr (eg type = Association setup) 1658 | 1659 | 1660 +--- T = LFBselect 1661 | | 1662 | +-- LFBCLASSID = FE object 1663 | | 1664 | | 1665 | +-- LFBInstance = 0x1 1666 | | 1667 | +--- T = Operation = SHOW 1668 | | 1669 | +-- Path-data to one or more attibutes 1670 | including FE NAME 1671 +--- T = LFBselect 1672 | 1673 +-- LFBCLASSID = FE Protocol object 1674 | 1675 | 1676 +-- LFBInstance = 0x1 1677 | 1678 +--- T = Operation = SHOW 1679 | 1680 +-- Path-data to one or more attibutes 1681 including suggested HB parameters 1683 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 1685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1686 | Type = LFB select | Length | 1687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1688 | LFB Class ID = FE Object | 1689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1690 | LFB Instance ID | 1691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1692 | Type = operation Show | Length | 1693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1694 | | 1695 ~ Attributes path and data ~ 1696 ~ ~ 1697 ~ ~ 1698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1699 | Type = LFB select | Length | 1700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1701 | LFB Class ID = FE Protocol Object | 1702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1703 | LFB Instance ID | 1704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1705 | Type = operation Show | Length | 1706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1707 | | 1708 ~ ~ 1709 ~ Attributes path and data ~ 1710 ~ ~ 1711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1713 Figure 12 1715 Type (16 bits): 1716 LFB Select 1718 Length (16 bits): 1719 Length of the TLV including the T and L fields, in bytes. 1721 FE Object and Protocol LFBs: 1722 These contains the FE parameters e.g. HBI will be exchanged with 1723 the CE using the FE Protocol LFB. 1725 6.4.2 Association Setup Response Message 1727 This message is sent by the CE to the FE in response to the Setup 1728 message. It indicates to the FE whether the setup is successful or 1729 not, i.e. whether an association is established. 1731 Message transfer direction: 1732 CE to FE 1734 Message Header: 1735 The Message Type in the header is set MessageType= 'Setup 1736 Response'. The ACK flag in the header is always ignored, because 1737 the setup response message will never expect to get any more 1738 response from the message receiver (FE). The Dst ID in the 1739 header will be set to some FE ID value assigned by the CE if the 1740 FE had requested that in the setup message (by SrcID = 0). 1742 Message body: 1743 The setup response message body consists of LFBSelect & Result 1744 TLV, the format of which is as follows: 1746 main hdr (eg type = Association setup response) 1747 | 1748 | 1749 | 1750 +--- T = LFBselect 1751 | | 1752 | +-- LFBCLASSID = FE object 1753 | | 1754 | | 1755 | +-- LFBInstance = 0x1 1756 | | 1757 | +--- T = Operation = SHOW 1758 | | 1759 | +-- Path-data to one or more attibutes 1760 | including FE NAME 1761 | May contain RESULT TLVs 1762 +--- T = LFBselect 1763 | 1764 +-- LFBCLASSID = FE Protocol object 1765 | 1766 | 1767 +-- LFBInstance = 0x1 1768 | 1769 +--- T = Operation = SHOW 1770 | 1771 +-- Path-data to one or more attibutes 1772 eg HB parameters 1773 May contain RESULT TLVs 1775 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 1777 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1778 | Type = LFB select | Length | 1779 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1780 | LFB Class ID = FE Object | 1781 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1782 | LFB Instance ID | 1783 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1784 | Type = operation Show | Length | 1785 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1786 | | 1787 ~ Attributes path and data ~ 1788 ~ ~ 1789 ~ ~ 1790 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1791 | Type = LFB select | Length | 1792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1793 | LFB Class ID = FE Protocol Object | 1794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1795 | LFB Instance ID | 1796 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1797 | Type = operation Show | Length | 1798 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1799 | | 1800 ~ ~ 1801 ~ Attributes path and data ~ 1802 ~ ~ 1803 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1805 Figure 13 1807 Type (16 bits): 1808 LFB Select 1810 Length (16 bits): 1811 Length of the TLV including the T and L fields, in bytes. 1813 FE Object LFB: 1814 The FE parameters e.g. HBI may be exchanged using this LFB. 1816 Result (16 bits): 1817 This indicates whether the setup msg was successful or whether 1818 the FE request was rejected by the CE. 1820 6.4.3 Association Teardown Message 1822 This message can be sent by the FE or CE to any ForCES element to end 1823 its ForCES association with that element. 1825 Message transfer direction: 1826 CE to FE, or FE to CE (or CE to CE) 1828 Message Header: 1829 The Message Type in the header is set MessageType= "Asso. 1830 Teardown". The ACK flag in the header is always ignored, because 1831 the teardown message will never expect to get any response from 1832 the message receiver. 1834 Message body: 1835 The association teardown message body consists of LFBSelect & 1836 FEReason TLV, the format of which is as follows: 1838 main hdr (eg type = Association tear) 1839 | 1840 | 1841 | 1842 | 1843 +--- T = LFBselect 1844 | 1845 +-- LFBCLASSID = FE object 1846 | 1847 | 1848 +-- LFBInstance = 0x1 1849 | 1850 +--- T = Operation = FEReason 1851 | 1852 +-- Path-data to string containing reason 1854 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 1856 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1857 | Type = LFB select | Length | 1858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1859 | LFB Class ID = FE Object | 1860 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1861 | LFB Instance ID | 1862 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1863 | Type = T.reason | Length | 1864 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1865 | Reason | 1866 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1868 Figure 14 1870 Type (16 bits): 1871 LFB Select 1873 Length (16 bits): 1874 Length of the TLV including the T and L fields, in bytes. 1876 T.reason (32 bits): 1877 This indicates the reason why the association is being 1878 terminated. 1880 6.5 Configuration Messages 1882 The ForCES Configuration messages are used by the CEs to configure 1883 the FEs in a ForCES NE and report the results back to the CE. 1885 6.5.1 Config Message 1887 This message is sent by the CE to the FE to configure FE or LFB 1888 attributes. This message is also used by the CE to subscribe/ 1889 unsubscribe to FE and LFB events. 1891 Message transfer direction: 1892 CE to FE 1894 Message Header: 1895 The Message Type in the header is set MessageType= 'Config'. The 1896 ACK flag in the header is can be used by the CE to turn off any 1897 response from the FE. The default behavior is to turn on the ACK 1898 to get the config response from the FE. 1900 Message body: 1901 The Config message body consists of one or more TLVs, the format 1902 of a single (LFB) TLV is as follows: 1904 main hdr (eg type = config) 1905 | 1906 | 1907 +--- T = LFBselect 1908 | | 1909 | +-- LFBCLASSID = target LFB class 1910 | | 1911 | | 1912 | +-- LFBInstance = target LFB instance 1913 | | 1914 | | 1915 | +-- T = operation { SET, DEL } 1916 | | | 1917 | | +-- // one or more path targets 1918 | | // discussed later 1919 | | 1920 | +-- T = operation { SET, DEL } 1921 | | | 1922 | | +-- // one or more path targets 1923 | | // discussed later 1924 | | 1925 | +-- T = operation { SET, DEL } 1926 | | | 1927 | | +-- // one or more path targets 1928 | | // discussed later 1929 | | 1931 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 1932 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1933 | Type = LFB select | Length | 1934 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1935 | LFB Class ID | 1936 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1937 | LFB Instance ID | 1938 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1939 | Operation (SET) | Length | 1940 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1941 | | 1942 ~ Config path ~ 1943 | | 1944 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1945 | Operations (DEL) | Length | 1946 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1947 | | 1948 ~ Config path ~ 1949 | | 1950 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1951 Figure 15 1953 Type (16 bits): 1954 LFB Select. 1956 Length (16 bits): 1957 Length of the TLV including the T and L fields, in bytes. 1959 LFB Class ID (16 bits): 1960 This field uniquely recognizes the LFB class/type. 1962 LFB Instance ID (16 bits): 1963 This field uniquely identifies the LFB instance. 1965 Type (16 bits): 1966 The operations include, ADD, DEL, UPDATE/REPLACE, DEL ALL, EVENT 1967 SUBSCRIBE, EVENT UNSUBSCRIBE, CANCEL. 1969 Length (16 bits): 1970 Length of the TLV including the T and L fields, in bytes. 1972 Config path + Data (variable length): 1973 This will carry LFB specific data (, presentation 1974 preliminary found in this doc but still TBD. ). The config data 1975 might itself be of the form of a TLV. Should be noted only a 1976 CREATE, REPLACE will have data while the rest will only carry 1977 path information of what to DELete or GET. 1979 *Note: FE Activate/Deactivate, Shutdown FE commands for State 1980 Maintenance will be sent using Config messages. 1982 *Note: For Event subscription, the events will be defines by the 1983 individual LFBs. 1985 6.5.2 Config Response Message 1987 This message is sent by the FE to the CE in response to the Config 1988 message. It indicates whether the Config was successful or not on 1989 the FE and also gives a detailed response regarding the configuration 1990 result of each attribute. 1992 Message transfer direction: 1993 FE to CE 1995 Message Header: 1996 The Message Type in the header is set MessageType= 'Config 1997 Response'. The ACK flag in the header is always ignored, because 1998 the config response message will never expect to get any more 1999 response from the message receiver (CE). 2001 Message body: 2002 The Config response message body consists of one or more TLVs, 2003 the format of a single TLV is as follows: 2005 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 2007 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2008 | Type = LFB select | Length | 2009 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2010 | LFB Class ID | 2011 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2012 | LFB Instance ID | 2013 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2014 | Operations (SET) | Length | 2015 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2016 | Operation Result | reserved | 2017 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2018 | | 2019 ~ Config Result ~ 2020 | | 2021 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2022 | Type = Operations (DEL) | Length | 2023 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2024 | Operation Result | reserved | 2025 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2026 | | 2027 ~ Config Result ~ 2028 | | 2029 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2031 Figure 16 2033 Type (16 bits): 2034 LFB Select. 2036 Length (16 bits): 2037 Length of the TLV including the T and L fields, in bytes. 2039 LFB Class ID (16 bits): 2040 This field uniquely recognizes the LFB class/type. 2042 LFB Instance ID (16 bits): 2043 This field uniquely identifies the LFB instance. 2045 Type (16 bits): 2046 The operations are same as those defined for Config messages. 2048 Length (16 bits): 2049 Length of the TLV including the T and L fields, in bytes. 2051 Operation Result (16 bits): 2052 This indicates the overall result of the config operation, 2053 whether it was successful or it failed. 2055 Config Result (variable length): 2056 This will carry LFB specific results (single or Array LFB 2057 specific result entries). The config result might itself be of 2058 the form of a TLV. 2060 6.6 Query and Query Response Messages 2062 The ForCES query and query response messages are used by ForCES 2063 elements (CE or FE) to query LFBs in other ForCES element(s) Current 2064 version of ForCES protocol limits the use of the messages only for CE 2065 to query information of FE. 2067 6.6.1 Query Message 2069 As usual, a query message is composed of a common header and a 2070 message body that consists of one or more TLV data format. Detailed 2071 description of the message is as below. 2073 Message transfer direction: 2074 Current version limits the query message transfer direction only 2075 from CE to FE. 2077 Message Header: 2078 The Message Type in the header is set to MessageType= 'Query'. 2079 The ACK flag in the header SHOULD be set 'ACKAll', meaning a full 2080 response for a query message is always expected. If the ACK flag 2081 is set other values, the meaning of the flag will then be 2082 ignored, and a full response will still be returned by message 2083 receiver. 2085 Message body: 2086 The query message body consists of (at least) one or more than 2087 one TLVs that describe entries to be queried. The TLV is called 2088 LFBselect TLV and the data format is as below: 2090 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 2091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2092 | Type = LFBselect | Length | 2093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2094 | LFB Class ID | 2095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2096 | LFB Instance ID | 2097 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2098 | Operation TLV | 2099 . . 2100 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2101 ~ ... ~ 2102 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2103 | Operation TLV | 2104 . . 2105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2107 Figure 17 2109 Operation TLV: 2110 The Operation TLV for the 'Query' message is formatted as: 2112 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2113 | Type = GET | Length | 2114 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2115 | PATH-DATA for GET | 2116 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2118 Figure 18 2120 PATH-DATA for GET: 2121 This is generically a PATH-DATA format that has been defined in 2122 "Protocol Grammar" section in the PATH-DATA BNF definition, with 2123 the limitation specifically for GET operation that the PATH-DATA 2124 here will not allow DATARAW-TLV and RESULT-TLV present in the 2125 data format, so as to meet the genius of a GET operation. 2127 To better understand the above PDU format, we can show a tree 2128 structure for the format as below: 2130 main hdr (type = Query) 2131 | 2132 | 2133 +--- T = LFBselect 2134 | | 2135 | +-- LFBCLASSID = target LFB class 2136 | | 2137 | | 2138 | +-- LFBInstance = target LFB instance 2139 | | 2140 | | 2141 | +-- T = operation { GET } 2142 | | | 2143 | | +-- // one or more path targets 2144 | | // under discussion 2145 | +-- T = operation { GET } 2146 | | | 2147 | | +-- // one or more path targets 2148 | | 2150 Figure 19 2152 6.6.2 Query Response Message 2154 When receiving a query message, the receiver should process the 2155 message and come up with a query result. The receiver sends the 2156 query result back to the message sender by use of the Query Response 2157 Message. The query result can be the information being queried if 2158 the query operation is successful, or can also be error codes if the 2159 query operation fails, indicating the reasons for the failure. 2161 A query response message is also composed of a common header and a 2162 message body consists of one or more TLVs describing the query 2163 result. Detailed description of the message is as below. 2165 Message transfer direction: 2166 Current version limits the query response message transfer 2167 direction only from FE to CE. 2169 Message Header: 2170 The Message Type in the header is set to MessageType= 2171 'QueryResponse'. The ACK flag in the header SHOULD be set 2172 'NoACK', meaning no further response for a query response message 2173 is expected. If the ACK flag is set other values, the meaning of 2174 the flag will then be ignored. The Sequence Number in the header 2175 SHOULD keep the same as that of the query message to be 2176 responded, so that the query message sender can keep track of the 2177 responses. 2179 Message body: 2180 The message body for a query response message consists of (at 2181 least) one or more than one TLVs that describe query results for 2182 individual queried entries. The TLV is also called LFBselect 2183 TLV, and has exactly the same data format as query message, 2184 except the Operation TLV content is different. The order of the 2185 TLV here matches the TLVs in the corresponding Query message, and 2186 the TLV numbers should also keep the same. The Operation TLV 2187 here is a 'GET-RESPONSE' TLV and the data is a 'PATH-DATA' 2188 format for Query Response Data, as below: 2190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2191 | Type = GET-RESPOSE | Length | 2192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2193 | PATH-DATA for GET-RESPONSE | 2194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2196 Figure 20 2198 PATH-DATA for GET-RESPONSE: 2199 This is generically a PATH-DATA format that has been defined in 2200 "Protocol Grammar" section in the PATH-DATA BNF definition. The 2201 response data will be included in the DATARAW-TLV and/or RESULT- 2202 TLV inside the PATH-DATA format. 2204 6.7 Event Notification and Response Messages 2206 The Event Notification Message is used to allow one ForCES element to 2207 asynchronously notify one or more other ForCES elements in the same 2208 ForCES NE on events occuring in that ForCES element. The Event 2209 Notification Response Message is used for the receiver of the Event 2210 Notification Message to acknowledge the reception of the event 2211 notification. 2213 Events in current ForCES protocol can be categorized into following 2214 types: 2216 o Events happened in CE 2218 o Events happened in FE 2220 Events can also be categorized into two classes according to whether 2221 they need subscription or not. An event in one ForCES element that 2222 needs to be subscribed will send notifications to other ForCES 2223 elements only when the other elements have subscribed to the element 2224 for the event notification. How to subscribe/unsubscribe for an 2225 event is described in the Configure Message section. An event that 2226 does not need to be subscribed will always send notifications to 2227 other ForCES elements when the event happens. Events will be defined 2228 in the ForCES FE model XML definitions for LFBs as attributes; i.e 2229 they will have a path to them that can be used by the config message 2230 to subscribe to. 2232 6.7.1 Event Notification Message 2234 As usual, an Event Notification Message is composed of a common 2235 header and a message body that consists of one or more TLV data 2236 format. Detailed description of the message is as below. 2238 Message Transfer Direction: 2239 FE to CE, or CE to FE 2241 Message Header: 2242 The Message Type in the message header is set to 2243 MessageType = 'EventNotification'. The ACK flag in the header can 2244 be set as: ACK flag ='NoACK'|'SuccessAck'|'UnsuccessACK'|'ACKAll'. 2245 Note that the 'Success' here only means the receiver of the 2246 message has successfully received the message. 2248 Message Body: 2249 The message body for an event notification message consists of (at 2250 least) one or more than one TLVs that describe the notified 2251 events. The TLV is defined as follows: 2253 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 2254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2255 | Type = LFBselect | Length | 2256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2257 | LFB Class ID | 2258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2259 | LFB Instance ID | 2260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2261 | Operation TLV | 2262 . . 2263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2264 ~ ... ~ 2265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2266 | Operation TLV | 2267 . . 2268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2270 Figure 21 2272 Operation TLV: 2273 This is a TLV that describes the event to be notified, as follows: 2275 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2276 | OPER = REPORT | Length | 2277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2278 | PATH-DATA for REPORT | 2279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2281 Figure 22 2283 PATH-DATA for REPORT: 2284 This is generically a PATH-DATA format that has been defined in 2285 "Protocol Grammar" section in the PATH-DATA BNF definition. The 2286 report data will be included in the DATARAW-TLV inside the PATH- 2287 DATA format. 2289 To better understand the above PDU format, we can show a tree 2290 structure for the format as below: 2292 main hdr (type = Event Notification) 2293 | 2294 | 2295 +--- T = LFBselect 2296 | | 2297 | +-- LFBCLASSID = target LFB class 2298 | | 2299 | | 2300 | +-- LFBInstance = target LFB instance 2301 | | 2302 | | 2303 | +-- T = operation { REPORT } 2304 | | | 2305 | | +-- // one or more path targets 2306 | | // under discussion 2307 | +-- T = operation { REPORT } 2308 | | | 2309 | | +-- // one or more path targets 2310 | | 2312 Figure 23 2314 6.7.2 Event Notification Response Message 2316 After sending out an Event Notification Message, the sender may be 2317 interested in ensuring that the message has been received by 2318 receivers, especially when the sender thinks the event notification 2319 is vital for system management. An Event Notification Response 2320 Message is used for this purpose. The ACK flag in the Event 2321 Notification Message header are used to signal if such acknowledge is 2322 requested or not by the sender. 2324 Detailed description of the message is as below: 2326 Message Transfer Direction: 2327 From FE to CE or from CE to FE, just inverse to the direction of 2328 the Event Notification Message that it responses. 2330 Message Header: 2331 The Message Type in the header is set MessageType= 2332 'EventNotificationResponse'. The ACK flag in the header SHOULD be 2333 set 'NoACK', meaning no further response for the message is 2334 expected. If the ACK flag is set other values, the meaning of the 2335 flag will then be ignored. The Sequence Number in the header 2336 SHOULD keep the same as that of the message to be responded, so 2337 that the event notificatin message sender can keep track of the 2338 responses. 2340 Message Body: 2341 The message body for an event notification response message 2342 consists of (at least) one or more than one TLVs that describe the 2343 notified events. The TLV is also called LFBselect TLV, and has 2344 exactly the same data format as Event Notification Message, except 2345 the Operation TLV inside is different. The order of the TLV here 2346 matches the TLVs in the corresponding Event Message, and the TLV 2347 numbers should keep the same. The Operation TLV here is a 2348 'REPORT-RESPONSE' TLV and the data is a 'PATH-DATA' format for 2349 event response data, as below: 2351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2352 | Type = REPORT-RESPONSE | Length | 2353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2354 | PATH-DATA for REPORT-RESPONSE | 2355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2357 Figure 24 2359 PATH-DATA for REPORT-RESPONSE: 2360 This is generically a PATH-DATA format that has been defined in 2361 "Protocol Grammar" section in the PATH-DATA BNF definition. The 2362 response data will be included in the RESULT-TLV inside the PATH- 2363 DATA format. 2365 6.8 Packet Redirect Message 2367 Packet redirect message is used to transfer data packets between CE 2368 and FE. Usually these data packets are IP packets, though they may 2369 sometimes associated with some metadata generated by other LFBs in 2370 the model, or they may occasionally be other protocol packets, which 2371 usually happen when CE and FE are jointly implementing some high- 2372 touch operations. Packets redirected from FE to CE are the data 2373 packets that come from forwarding plane, and usually are the data 2374 packets that need high-touch operations in CE,or packets for which 2375 the IP destination address is the NE. Packets redirected from CE to 2376 FE are the data packets that come from the CE and are decided by CE 2377 to put into forwarding plane in FE. 2379 Supplying such a redirect path between CE and FE actually leads to a 2380 possibility of this path being DoS attacked. Attackers may 2381 maliciously try to send huge spurious packets that will be redirected 2382 by FE to CE, making the redirect path been congested. ForCES 2383 protocol and the TML layer will jointly supply approaches to prevent 2384 such DoS attack. To define a specific 'Packet Redirect Message' 2385 makes TML and CE able to distinguish the redirect messages from other 2386 ForCES protocol messages. 2388 By properly configuring related LFBs in FE, a packet can also be 2389 mirrored to CE instead of purely redirected to CE, i.e., the packet 2390 is duplicated and one is redirected to CE and the other continues its 2391 way in the LFB topology. 2393 The Packet Redirect Message data format is formated as follows: 2395 Message Direction: 2396 CE to FE or FE to CE 2398 Message Header: 2399 The Message Type in the header is set to MessageType= 2400 'PacketRedirect'. The ACK flags in the header SHOULD be set 2401 'NoACK', meaning no response is expected by this message. If the 2402 ACK flag is set other values, the meanings will be ignored. 2404 Message Body: 2405 Consists of one or more TLVs, with every TLV having the following 2406 data format: 2408 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 2409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2410 | Type = LFBselect | Length | 2411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2412 | LFB Class ID | 2413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2414 | LFB Instance ID | 2415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2416 | Operation TLV | 2417 . . 2418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2419 ~ ... ~ 2420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2421 | Operation TLV | 2422 . . 2423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2425 Figure 25 2427 LFB class ID: 2428 There are only two possible LFB classes here, the 'RedirectSink' 2429 LFB or the 'RedirectTap' LFB. If the message is from FE to CE, 2430 the LFB class should be 'RedirectSink'. If the message is from CE 2431 to FE, the LFB class should be 'RedirectTap'. 2433 Instance ID: 2434 Instance ID for the 'RedirectSink' LFB or 'RedirectTap' LFB. 2436 Operation TLV: 2437 This is a TLV describing one packet of data to be directed via the 2438 specified LFB above. The order of the data number is also the 2439 order the data packet arrives the redirector LFB, that is, the 2440 Redirected Data #1 should arrive earlier than the Redirected Data 2441 #2 in this redirector LFB. The TLV format is as follows: 2443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2444 | Type = PAYLOAD | Length | 2445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2446 | Path(or Sequence Number?) | 2447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2448 ~ Redirected Data ~ 2449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2451 Figure 26 2453 Path(or Sequence Number?): 2454 [Under discussion and TBD] 2456 Type: 2457 [TBD] 2459 Redirected Data: 2460 This field will make a detailed description of the data to be 2461 redirected as well as the data itself. The encoding of the 2462 description is based on the ForCES FE model if the redirector LFB 2463 is defined by FE model, or based on vendor specifications if the 2464 redirector LFB is defined by vendors. The description will 2465 usually include the name (or the name ID) of the redirected packet 2466 data (such as 'IPv4 Packet', 'IPv6 Packet'), and the packet data 2467 itself. It may also include some metadata (metadata name (or name 2468 ID) and its value)associated with the redirected data packet. 2470 6.9 Heartbeat Message 2472 The Heartbeat (HB) Message is used for one ForCES element (FE or CE) 2473 to asynchronously notify one or more other ForCES elements in the 2474 same ForCES NE on its liveness. 2476 A Heartbeat Message is sent by a ForCES element periodically. The 2477 time interval to send the message is set by the Association Setup 2478 Message described in Section 6.1.1. A little different from other 2479 protocol messages, a Heartbeat message is only composed of a common 2480 header, withe the message body left empty. Detailed description of 2481 the message is as below. 2483 Message Transfer Direction: 2484 FE to CE, or CE to FE 2486 Message Header: 2487 The Message Type in the message header is set to MessageType = 2488 'Heartbeat'. The ACK flag in the header SHOULD be set to 2489 'NoACK', meaning no response from receiver(s) is expected by the 2490 message sender. Other values of the ACK flag will always be 2491 ignored by the message receiver. 2493 Message Body: 2494 The message body is empty for the Heartbeat Message. 2496 6.10 Operation Summary 2498 The following tables summarize the operations and their applicabiity 2499 to the messages. 2501 No Operations for the following messages: 2503 Assoc-Setup 2505 Assoc-Setup-Resp 2507 Assoc-Teardown 2509 Heartbeat 2511 +-------------------+-------+------------+--------+-------------+ 2512 | Operation | Query | Query-Resp | Config | config-Resp | 2513 +-------------------+-------+------------+--------+-------------+ 2514 | Set | | | X | X | 2515 | | | | | | 2516 | Delete | | | X | X | 2517 | | | | | | 2518 | Update | | | X | X | 2519 | | | | | | 2520 | Get | X | X | | | 2521 | | | | | | 2522 | Event subscribe | | | X | X | 2523 | | | | | | 2524 | Event unsubscribe | | | X | X | 2525 +-------------------+-------+------------+--------+-------------+ 2527 +-----------+--------------+-------------+------------------+ 2528 | Operation | Packet-Redir | Event-Notif | Event-Notif-Resp | 2529 +-----------+--------------+-------------+------------------+ 2530 | Payload | X | | | 2531 | | | | | 2532 | Event | | X | X | 2533 +-----------+--------------+-------------+------------------+ 2535 7. Protocol Scenarios 2537 7.1 Association Setup state 2539 The associations among CEs and FEs are initiated via Association 2540 setup message from the FE. If a setup request is granted by the CE, 2541 a successful setup response message is sent to the FE. If CEs and 2542 FEs are operating in an insecure environment then the security 2543 association have to be established between them before any 2544 association messages can be exchanged. The TML will take care of 2545 establishing any security associations. 2547 This is followed by capability query, topology query. When the FE is 2548 ready to start forwarding data traffic, it sends a FE UP Event 2549 message to the CE. The CE responds with a FE ACTIVATE State 2550 Maintenance message to ask the FE to go active and start forwarding 2551 data traffic. At this point the association establishment is 2552 complete. These sequences of messages are illustrated in the Figure 2553 below. 2555 FE PL CE PL 2557 | | 2558 | Asso Setup Req | 2559 |---------------------->| 2560 | | 2561 | Asso Setup Resp | 2562 |<----------------------| 2563 | | 2564 | Capability Query | 2565 |<----------------------| 2566 | | 2567 | Query Resp | 2568 |---------------------->| 2569 | | 2570 | Topo Query | 2571 |<----------------------| 2572 | | 2573 | Topo Query Resp | 2574 |---------------------->| 2575 | | 2576 | FE UP Event | 2577 |---------------------->| 2578 | | 2579 | Config-Activate FE | 2580 |<----------------------| 2581 | | 2583 Figure 27: Message exchange between CE and FE to establish an NE 2584 association 2586 On successful completion of this state, the FE joins the NE and is 2587 moved to the Established State or Steady state. 2589 7.2 Association Established state or Steady State 2591 In this state the FE is continously updated or queried. The FE may 2592 also send asynchronous event notifications to the CE or synchronous 2593 heartbeat messages. This continues until a termination (or 2594 deactivation) is initiated by either the CE or FE. Figure below 2595 helps illustrate this state. 2597 FE PL CE PL 2599 | | 2600 | Heart Beat | 2601 |<----------------------| 2602 | | 2603 | Heart Beat | 2604 |---------------------->| 2605 | | 2606 | Config-Subscribe Ev | 2607 |<----------------------| 2608 | | 2609 | Config Resp | 2610 |---------------------->| 2611 | | 2612 | Config-Add LFB Attr | 2613 |<----------------------| 2614 | | 2615 | Config Resp | 2616 |---------------------->| 2617 | | 2618 | Query LFB Stats | 2619 |<----------------------| 2620 | | 2621 | Query Resp | 2622 |---------------------->| 2623 | | 2624 | FE Event Report | 2625 |---------------------->| 2626 | | 2627 | Config-Del LFB Attr | 2628 |<----------------------| 2629 | | 2630 | Config Resp | 2631 |---------------------->| 2632 | | 2633 | Packet Redirect | 2634 |---------------------->| 2635 | | 2636 | Heart Beat | 2637 |<----------------------| 2638 . . 2639 . . 2640 | | 2641 | Config-Activate FE | 2642 |<----------------------| 2643 | | 2645 Figure 28: Message exchange between CE and FE during steady-state 2646 communication 2648 Note that the sequence of messages shown in the figure serve only as 2649 examples and the messages exchange sequences could be different from 2650 what is shown in the figure. Also, note that the protocol scenarios 2651 described in this section do not include all the different message 2652 exchanges which would take place during failover. That is described 2653 in the HA section 8. 2655 8. High Availability Support 2657 The ForCES protocol provides mechanisms for CE redundancy and 2658 failover, in order to support High Availability as defined in 2659 [RFC3654]. FE redundancy and FE to FE interaction is currently out 2660 of scope of this draft. There can be multiple redundant CEs and FEs 2661 in a ForCES NE. However, at any time there can only be one Primary 2662 CE controlling the FEs and there can be multiple secondary CEs. The 2663 FE and the CE PL are aware of the primary and secondary CEs. This 2664 information (primary, secondary CEs) is configured in the FE, CE PLs 2665 during pre-association by FEM, CEM respectively. Only the primary CE 2666 sends Control messages to the FEs. The FE may send its event 2667 reports, redirection packets to only the Primary CE (Report Primary 2668 Mode) or it may send these to both primary and secondary CEs (Report 2669 All Mode). (The latter helps with keeping state between CEs 2670 synchronized, although it does not guarantee synchronization.) This 2671 behavior or HA Modes are configured during Association setup phase 2672 but can be changed by the CE anytime during protocol operation. A 2673 CE-to-CE synchronization protocol will be needed in most cases to 2674 support fast failover, however this will not be defined by the ForCES 2675 protocol. 2677 During a communication failure between the FE and CE (which is caused 2678 due to CE or link reasons, i.e. not FE related), the TML on the FE 2679 will trigger the FE PL regarding this failure. This can also be 2680 detected using the HB messages between FEs and CEs. The FE PL will 2681 send a message (Event Report) to the Secondary CEs to indicate this 2682 failure or the CE PL will detect this and one of the Secondary CEs 2683 takes over as the primary CE for the FE. During this phase, if the 2684 original primary CE comes alive and starts sending any commands to 2685 the FE, the FE should ignore those messages and send an Event to all 2686 CEs indicating its change in Primary CE. Thus the FE only has one 2687 primary CE at a time. 2689 An explicit message (Config message- Move command) from the primary 2690 CE, can also be used to change the Primary CE for an FE during normal 2691 protocol operation. In order to support fast failover, the FE will 2692 establish association (setup msg) as well as complete the capability 2693 exchange with the Primary as well as all the Secondary CEs (in all 2694 scenarios/modes). 2696 These two scenarios (Report All, Report Primary) have been 2697 illustrated in the figures below. 2699 FE CE Primary CE Secondary 2700 | | | 2701 | Asso Estb,Caps exchg | | 2702 1 |<--------------------->| | 2703 | | | 2704 | Asso Estb,Caps|exchange | 2705 2 |<----------------------|------------------->| 2706 | | | 2707 | All msgs | | 2708 3 |<--------------------->| | 2709 | | | 2710 | packet redirection,|events, HBs | 2711 4 |-----------------------|------------------->| 2712 | | | 2713 | FAILURE | 2714 | | 2715 | Event Report (pri CE down) | 2716 5 |------------------------------------------->| 2717 | | 2718 | All Msgs | 2719 6 |------------------------------------------->| 2721 Figure 29: CE Failover for Report All mode 2723 FE CE Primary CE Secondary 2724 | | | 2725 | Asso Estb,Caps exchg | | 2726 1 |<--------------------->| | 2727 | | | 2728 | Asso Estb,Caps|exchange | 2729 2 |<----------------------|------------------->| 2730 | | | 2731 | All msgs | | 2732 3 |<--------------------->| | 2733 | | | 2734 | (HeartBeats| only) | 2735 4 |-----------------------|------------------->| 2736 | | | 2737 | FAILURE | 2738 | | 2739 | Event Report (pri CE down) | 2740 5 |------------------------------------------->| 2741 | | 2742 | All Msgs | 2743 6 |------------------------------------------->| 2745 Figure 30: CE Failover for Report Primary Mode 2747 8.1 Responsibilities for HA 2749 TML level - Transport level: 2751 1. The TML controls logical connection availability and failover. 2753 2. The TML also controls peer HA managements. 2755 At this level, control of all lower layers, for example transport 2756 level (such as IP addresses, MAC addresses etc) and associated links 2757 going down are the role of the TML. 2759 PL Level: 2760 All the other functionality including configuring the HA behavior 2761 during setup, the CEIDs are used to identify primary, secondary CEs, 2762 protocol Messages used to report CE failure (Event Report), Heartbeat 2763 messages used to detect association failure, messages to change 2764 primary CE (config - move), and other HA related operations described 2765 before are the PL responsibility. 2767 To put the two together, if a path to a primary CE is down, the TML 2768 would take care of failing over to a backup path, if one is 2769 available. If the CE is totally unreachable then the PL would be 2770 informed and it will take the appropriate actions described before. 2772 9. Security Considerations 2774 ForCES architecture identified several [Reference Arch] levels of 2775 security. ForCES PL uses security services provided by the ForCES 2776 TML layer. TML layer provides security services such as endpoint 2777 authentication service, message authentication service and 2778 confidentiality service. Endpoint authentication service is invoked 2779 at the time of pre-association connection establishment phase and 2780 message authentication is performed whenever FE or CE receives a 2781 packet from its peer. 2783 Following are the general security mechanism that needs to be in 2784 place for ForCES PL layer. 2786 o Security mechanism are session controlled that is once the 2787 security is turned ON depending upon the chosen security level (No 2788 Security, Authentication only, Confidentiality), it will be in 2789 effect for the entire duration of the session. 2791 o Operator should configure the same security policies for both 2792 primary and backup FE's and CE's (if available). This will ensure 2793 uniform operations, and to avoid unnecessary complexity in policy 2794 configuration. 2796 o ForCES PL endpoints SHOULD pre-established connections with both 2797 primary and backup CE's. This will reduce the security messages 2798 and enable rapid switchover operations for HA. 2800 9.1 No Security 2802 When No security is chosen for ForCES protocol communication, both 2803 endpoint authentication and message authentication service needs be 2804 performed by ForCES PL layer. Both these mechanism are weak and does 2805 not involve cryptographic operation. Operator can choose "No 2806 security" level when the ForCES protocol endpoints are within an 2807 single box. 2809 In order to have interoperable and uniform implementation across 2810 various security levels, each CE and FE endpoint MUST implement this 2811 level. The operations that are being performed for "No security" 2812 level is required even if lower TML security services are being used. 2814 9.1.1 Endpoint Authentication 2816 Each CE and FE PL layer maintain set of associations list as part of 2817 configuration. This is done via CEM and FEM interfaces. FE MUST 2818 connect to only those CE's that are configured via FEM similarly CE 2819 should accept the connection and establish associations for the FE's 2820 which are configured via CEM. CE should validate the FE identifier 2821 before accepting the connection during the pre-association phase. 2823 9.1.2 Message authentication 2825 When CE or FE generates initiates a message, the receiving endpoint 2826 MUST validate the initiator of the message by checking the common 2827 header CE or FE identifiers. This will ensure proper protocol 2828 functioning. We recommend this extra step processing even if the 2829 underlying TLM layer security services. 2831 9.2 ForCES PL and TML security service 2833 This section is applicable if operator wishes to use the TML security 2834 services. ForCES TML layer MUST support one or more security service 2835 such as endpoint authentication service, message authentication 2836 service, confidentiality service as part of TML security layer 2837 functions. It is the responsibility of the operator to select 2838 appropriate security service and configure security policies 2839 accordingly. The details of such configuration is outside the scope 2840 of ForCES PL and is depending upon the type of transport protocol, 2841 nature of connection. 2843 All these configurations should be done prior to starting the CE and 2844 FE. 2846 When certificates-based authentication is being used at TML layer, 2847 the certificate can use ForCES specific naming structure as 2848 certificate names and accordingly the security policies can be 2849 configured at CE and FE. 2851 9.2.1 Endpoint authentication service 2853 When TML security services are enabled. ForCES TML layer performs 2854 endpoint authentication. Security association is established between 2855 CE and FE and is transparent to the ForCES PL layer. 2857 We recommend that FE after establishing the connection with the 2858 primary CE, should establish the security association with the backup 2859 CE (if available). During the switchover operation CE's security 2860 state associated with each SA's are not transferred. SA between 2861 primary CE and FE and backup CE and FE are treated as two separate 2862 SA's. 2864 9.2.2 Message authentication service 2866 This is TML specific operation and is transparent to ForCES PL 2867 layer[TML document]. 2869 9.2.3 Confidentiality service 2871 This is TML specific operation and is transparent to ForCES PL 2872 layer.[TML document] 2874 10. Acknowledgments 2876 The authors of this draft would like to acknowledge and thank the 2877 following: Alex Audu, Steven Blake, Allan DeKok, Ellen M. Deleganes, 2878 Yunfei Guo, Joel M. Halpern, Zsolt Haraszti, Jeff Pickering, 2879 Guangming Wang, Chaoping Wu, Lily L. Yang, and Alistair Munro for 2880 their contributions. We would also like to thank David Putzolu, and 2881 Patrick Droz for their comments and suggestions on the protocol. 2883 11. References 2885 11.1 Normative References 2887 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 2888 June 1999. 2890 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 2891 of IP Control and Forwarding", RFC 3654, November 2003. 2893 [RFC3746] Yang, L., Dantu, R., Anderson, T., and R. Gopal, 2894 "Forwarding and Control Element Separation (ForCES) 2895 Framework", RFC 3746, April 2004. 2897 11.2 Informational References 2899 [ACID] Haerder, T. and A. Reuter, "Principles of Transaction- 2900 Orientated Database Recovery", 1983. 2902 [FE-MODEL] 2903 Yang, L., Halpern, J., Gopal, R., DeKok, A., Haraszti, Z., 2904 and S. Blake, "ForCES Forwarding Element Model", 2905 Feb. 2005. 2907 Author's Address 2909 Avri Doria 2910 ETRI 2911 Lulea University of Technology 2912 Lulea 2913 Sweden 2915 Phone: +1 401 663 5024 2916 Email: avri@acm.org 2918 Appendix A. Individual Authors/Editors Contact 2920 Ligang Dong 2921 Zhejiang Gongshang University 2922 149 Jiaogong Road 2923 Hangzhou 310035 2924 P.R.China 2925 Phone: +86-571-88071024 2926 EMail: donglg@mail.hzic.edu.cn 2928 Avri Doria 2929 ETRI 2930 EMail: avri@acm.org 2932 Ram Gopal 2933 Nokia 2934 5, Wayside Road 2935 Burlington MA 01803 2936 USA 2937 Phone: 1-781-993-3685 2938 EMail: ram.gopal@nokia.com 2940 Robert Haas 2941 IBM 2942 Saumerstrasse 4 2943 8803 Ruschlikon 2944 Switzerland 2945 EMail: rha@zurich.ibm.com 2947 Jamal Hadi Salim 2948 Znyx 2949 Ottawa, Ontario 2950 Canada 2951 EMail: hadi@znyx.com 2953 Hormuzd M Khosravi 2954 Intel 2955 2111 NE 25th Avenue 2956 Hillsboro, OR 97124 2957 USA 2958 Phone: +1 503 264 0334 2959 EMail: hormuzd.m.khosravi@intel.com 2960 Weiming Wang 2961 Zhejiang Gongshang University 2962 149 Jiaogong Road 2963 Hangzhou 310035 2964 P.R.China 2965 Phone: +86-571-88057712 2966 EMail: wmwang@mail.hzic.edu.cn 2968 Appendix B. IANA considerations 2970 tbd 2972 Appendix C. Forces Protocol LFB schema 2974 The schema described below conforms to the LFB schema (language?) 2975 described in Forces Model draft[FE-MODEL] 2977 2982 2983 2984 2985 FEPO 2986 1 2987 2988 The FE Protocol Object 2989 2990 1.0 2991 baseclass 2992 2993 2994 HBstate 2995 2 2996 2997 Heartbeat event status(yes/no) 2998 2999 boolean 3000 3001 3002 3003 3004 SupportableVersions 3005 1 3006 3007 the table of ForCES versions that FE supports 3008 3009 3010 u8 3011 3012 3013 3014 3015 3016 HBI 3017 3 3018 Heartbeat Interval in millisecs 3019 uint32 3021 3022 3023 HBDI 3024 4 3025 Heartbeat Dead Interval in millisecs 3026 uint32 3027 3028 3029 CurrentRunningVersion 3030 5 3031 Currently running ForCES version 3032 u8 3033 3034 3035 3036 3037 3039 C.1 Events 3041 At the moment only one event, HBstate, can be subscribed to by the 3042 CE. 3044 By subscribing to the HBstate event, the CE infact kicks the FE into 3045 motion to start issuing heartbeats. 3047 C.2 Capabilities 3049 At the moment only the SupportableVersions capability is owned by 3050 this LFB. 3052 Supportable Versions enumerates all ForCES versions that an FE 3053 supports. 3055 C.3 Attributes 3057 C.3.1 HBI 3059 This attribute carries the Heartbeat Interval of the heartbeat from 3060 the FE -> CE in millisecs. The value of this interval is by default 3061 set by the FE but could be overwritten in the association setup by 3062 the CE. 3064 TBD (this really belongs in the protocol draft but here for capture 3065 purposes: 3067 Define it as simply that the CE and FE must hear from each other at 3068 the configured interval. The FE on her side generates a heartbeat 3069 notification if he has nothing else to say. In otehr words, The lack 3070 of any messages from the CE to which the FE responded to after a 3071 period of HBI will result in a FE firing a HB message. The lack of 3072 any message within DeadInterval will force the FE to ask for an ACK 3073 for its HB message (by setting the ACK flag in the header). 3075 Other adaptive heartbeats schemes which could be used: have the CE 3076 adjust the FE timers depending on the number of FEs present. 3077 Example, its 1 sec for upto 100 FEs and 2 seconds for [101,200] 4 3078 seconds interval for > 200 nodes etc ... Some adaptation of this is 3079 used by mmusic mbus protocol. 3081 C.3.2 HBDI 3083 This attribute carries the Heartbeat Dead Interval in millisecs. 3085 TBD: 3087 The original goal for HBDI was for HA purposes - to discover if the 3088 CE is still around by sending a heartbeat message to the CE with an 3089 ACK flag in the mainheader to request for a response. This hasnt 3090 been discussed in details yet; however, the general view at the time 3091 was for the FE to associate (failover) to another CE after that 3092 deadinterval period of not hearing from the CE - as defined by policy 3093 which resides in that same LFB definition. Two such failover 3094 methodologies are mentiooned briefly infact in the protocol draft but 3095 since the current attributes are unknown, the details are missing 3096 from the xml. 3098 C.3.3 CurrentRunningVersion 3100 This attribute describes which version of ForCES is currently 3101 running. 3103 Appendix D. Use Cases 3105 Assume LFB with following attributes for the following use cases. 3107 foo1, type u32, ID = 1 3109 foo2, type u32, ID = 2 3111 table1: type array, ID = 3 3112 elements are: 3113 t1, type u32, ID = 1 3114 t2, type u32, ID = 2 // index into table 2 3115 KEY: nhkey, ID = 1, V = t2 3117 table2: type array, ID = 4 3118 elements are: 3119 j1, type u32, ID = 1 3120 j2, type u32, ID = 2 3121 KEY: akey, ID = 1, V = { j1,j2 } 3123 table3: type array, ID = 5 3124 elements are: 3125 someid, type u32, ID = 1 3126 name, type string variable sized, ID = 2 3128 table4: type array, ID = 6 3129 elements are: 3130 j1, type u32, ID = 1 3131 j2, type u32, ID = 2 3132 j3, type u32, ID = 3 3133 j4, type u32, ID = 4 3134 KEY: mykey, ID = 1, V = { j1} 3136 table5: type array, ID = 7 3137 elements are: 3138 p1, type u32, ID = 1 3139 p2, type array, ID = 2, array elements of type-X 3141 Type-X: 3142 x1, ID 1, type u32 3143 x2, ID2 , type u32 3144 KEY: tkey, ID = 1, V = { x1} 3146 All examples will show an attribute suffixed with "v" or "val" to 3147 indicate the value of the referenced attribute. example for attribute 3148 foo2, foo1v or foo1value will indicate the value of foo1. In the 3149 case where F_SEL** are missing (bits equal to 00) then the flags will 3150 not show any selection. 3152 1. To get foo1 3154 OPER = GET-TLV 3155 Path-data TLV: IDCount = 1, IDs = 1 3156 Result: 3157 OPER = GET-RESPONSE-TLV 3158 Path-data-TLV: 3159 flags=0, IDCount = 1, IDs = 1 3160 DATARAW-TLV L = 4+4, V = foo1v 3162 2. To set foo2 to 10 3164 OPER = SET-REPLACE-TLV 3165 Path-data-TLV: 3166 flags = 0, IDCount = 1, IDs = 2 3167 DATARAW TLV: L = 4+4, V=10 3169 Result: 3170 OPER = SET-RESPONSE-TLV 3171 Path-data-TLV: 3172 flags = 0, IDCount = 1, IDs = 2 3173 RESULT-TLV 3175 3. To dump table2 3177 OPER = GET-TLV 3178 Path-data-TLV: 3179 IDCount = 1, IDs = 4 3180 Result: 3181 OPER = GET-RESPONSE-TLV 3182 Path-data-TLV: 3183 flags = 0, IDCount = 1, IDs = 4 3184 DATARAW=TLV: L = XXX, V= 3185 a series of: index, j1value,j2value entries 3186 representing the entire table 3188 4. Note: One should be able to take a GET-RESPONSE-TLV and convert 3189 it to a SET-REPLACE-TLV. If the result in the above example is 3190 sent back in a SET-REPLACE-TLV, (instead of a GET-RESPONSE_TLV) 3191 then the entire contents of the table will be replaced at that 3192 point. 3194 5. Multiple operations Example. To create entry 0-5 of table2 3195 (Ignore error conditions for now) 3197 OPER = SET-CREATE-TLV 3198 Path-data-TLV: 3199 flags = 0 , IDCount = 1, IDs=4 3200 PATH-DATA-TLV 3201 flags = 0, IDCount = 1, IDs = 0 3202 DATARAW-TLV containing j1, j2 value for entry 0 3203 PATH-DATA-TLV 3204 flags = 0, IDCount = 1, IDs = 1 3205 DATARAW-TLV containing j1, j2 value for entry 1 3206 PATH-DATA-TLV 3207 flags = 0, IDCount = 1, IDs = 2 3208 DATARAW-TLV containing j1, j2 value for entry 2 3209 PATH-DATA-TLV 3210 flags = 0, IDCount = 1, IDs = 3 3211 DATARAW-TLV containing j1, j2 value for entry 3 3212 PATH-DATA-TLV 3213 flags = 0, IDCount = 1, IDs = 4 3214 DATARAW-TLV containing j1, j2 value for entry 4 3215 PATH-DATA-TLV 3216 flags = 0, IDCount = 1, IDs = 5 3217 DATARAW-TLV containing j1, j2 value for entry 5 3219 Result: 3220 OPER = SET-RESPONSE-TLV 3221 Path-data-TLV: 3222 flags = 0 , IDCount = 1, IDs=4 3223 PATH-DATA-TLV 3224 flags = 0, IDCount = 1, IDs = 0 3225 RESULT-TLV 3226 PATH-DATA-TLV 3227 flags = 0, IDCount = 1, IDs = 1 3228 RESULT-TLV 3229 PATH-DATA-TLV 3230 flags = 0, IDCount = 1, IDs = 2 3231 RESULT-TLV 3232 PATH-DATA-TLV 3233 flags = 0, IDCount = 1, IDs = 3 3234 RESULT-TLV 3235 PATH-DATA-TLV 3236 flags = 0, IDCount = 1, IDs = 4 3237 RESULT-TLV 3238 PATH-DATA-TLV 3239 flags = 0, IDCount = 1, IDs = 5 3240 RESULT-TLV 3242 6. Block operations (with holes) example. Replace entry 0,2 of 3243 table2 3245 OPER = SET-REPLACE-TLV 3246 Path-data TLV: 3247 flags = 0 , IDCount = 1, IDs=4 3248 PATH-DATA-TLV 3249 flags = 0, IDCount = 1, IDs = 0 3250 DATARAW-TLV containing j1, j2 value for entry 0 3251 PATH-DATA-TLV 3252 flags = 0, IDCount = 1, IDs = 2 3253 DATARAW-TLV containing j1, j2 value for entry 2 3255 Result: 3256 OPER = SET-REPLACE-TLV 3257 Path-data TLV: 3258 flags = 0 , IDCount = 1, IDs=4 3259 PATH-DATA-TLV 3260 flags = 0, IDCount = 1, IDs = 0 3261 RESULT-TLV 3262 PATH-DATA-TLV 3263 flags = 0, IDCount = 1, IDs = 2 3264 RESULT-TLV 3266 7. Getting rows example. Get first entry of table2. 3268 OPER = GET-TLV 3269 Path-data TLV: 3270 IDCount = 2, IDs=4.0 3272 Result: 3273 OPER = GET-RESPONSE-TLV 3274 Path-data TLV: 3275 IDCount = 2, IDs=4.0 3276 DATARAW TLV, Length = XXX, V = 3277 j1value,j2value entry 3279 8. Get entry 0-5 of table2. 3281 OPER = GET-TLV 3282 Path-data-TLV: 3283 flags = 0, IDCount = 1, IDs=4 3284 PATH-DATA-TLV 3285 flags = 0, IDCount = 1, IDs = 0 3286 PATH-DATA-TLV 3287 flags = 0, IDCount = 1, IDs = 1 3288 PATH-DATA-TLV 3289 flags = 0, IDCount = 1, IDs = 2 3290 PATH-DATA-TLV 3291 flags = 0, IDCount = 1, IDs = 3 3292 PATH-DATA-TLV 3293 flags = 0, IDCount = 1, IDs = 4 3294 PATH-DATA-TLV 3295 flags = 0, IDCount = 1, IDs = 5 3297 Result: 3298 OPER = GET-RESPONSE-TLV 3299 Path-data-TLV: 3300 flags = 0, IDCount = 1, IDs=4 3301 PATH-DATA-TLV 3302 flags = 0, IDCount = 1, IDs = 0 3303 DATARAW-TLV containing j1value j2value 3304 PATH-DATA-TLV 3305 flags = 0, IDCount = 1, IDs = 1 3306 DATARAW-TLV containing j1value j2value 3307 PATH-DATA-TLV 3308 flags = 0, IDCount = 1, IDs = 2 3309 DATARAW-TLV containing j1value j2value 3310 PATH-DATA-TLV 3311 flags = 0, IDCount = 1, IDs = 3 3312 DATARAW-TLV containing j1value j2value 3313 PATH-DATA-TLV 3314 flags = 0, IDCount = 1, IDs = 4 3315 DATARAW-TLV containing j1value j2value 3316 PATH-DATA-TLV 3317 flags = 0, IDCount = 1, IDs = 5 3318 DATARAW-TLV containing j1value j2value 3320 9. Create a row in table2, index 5. 3322 OPER = SET-CREATE-TLV 3323 Path-data-TLV: 3324 flags = 0, IDCount = 2, IDs=4.5 3325 DATARAW TLV, Length = XXX 3326 j1value,j2value 3328 Result: 3329 OPER = SET-RESPONSE-TLV 3330 Path-data TLV: 3331 flags = 0, IDCount = 1, IDs=4.5 3332 RESULT-TLV 3334 10. An example of "create and give me an index" Assuming we asked 3335 for verbose response back in the main message header. 3337 OPER = SET-CREATE-TLV 3338 Path-data -TLV: 3339 flags = FIND-EMPTY, IDCount = 1, IDs=4 3340 DATARAW TLV, Length = XXX 3341 j1value,j2value 3343 Result 3344 If 7 were the first unused entry in the table: 3345 OPER = SET-RESPONSE 3346 Path-data TLV: 3347 flags = 0, IDCount = 2, IDs=4.7 3348 RESULT-TLV indicating success, and 3349 DATARAW-TLV, Length = XXX j1value,j2value 3351 11. Dump contents of table1. 3353 OPER = GET-TLV 3354 Path-data TLV: 3355 flags = 0, IDCount = 1, IDs=3 3357 Result: 3358 OPER = GET-RESPONSE-TLV 3359 Path-data TLV 3360 flags = 0, IDCount = 1, IDs=3 3361 DATARAW TLV, Length = XXXX 3362 (depending on size of table1) 3363 index, t1value, t2value 3364 index, t1value, t2value 3365 . 3367 . 3368 . 3370 12. Using Keys. Get row entry from table4 where j1=100. Recall, j1 3371 is a defined key for this table and its keyid is 1. 3373 OPER = GET-TLV 3374 Path-data-TLV: 3375 flags = F_SELKEY IDCount = 1, IDs=6 3376 KEYINFO-TLV = KEYID=1, KEY_DATA=100 3378 Result: 3379 If j1=100 was at index 10 3380 OPER = GET-RESPONSE-TLV 3381 Path-data TLV: 3382 flags = 0, IDCount = 1, IDs=6.10 3383 DATARAW TLV, Length = XXXX 3384 j1value,j2value, j3value, j4value 3386 13. Delete row with KEY match (j1=100, j2=200) in table 2. Note 3387 that the j1,j2 pair are a defined key for the table 2. 3389 OPER = DEL-TLV 3390 Path-data TLV: 3391 flags = F_SELKEY IDCount = 1, IDs=4 3392 KEYINFO TLV: {KEYID =1 KEY_DATA=100,200} 3394 Result: 3395 If (j1=100, j2=200) was at entry 15: 3396 OPER = DELETE-RESPONSE-TLV 3397 Path-data TLV: 3398 flags = 0 IDCount = 2, IDs=4.15 3399 RESULT-TLV (with DATARAW if verbose) 3401 14. Dump contents of table3. It should be noted that this table has 3402 a column with element name that is variable sized. The purpose 3403 of this use case is to show how such an element is to be 3404 encoded. 3406 OPER = GET-TLV 3407 Path-data-TLV: 3408 flags = 0 IDCount = 1, IDs=5 3410 Result: 3411 OPER = GET-RESPONSE-TLV 3412 Path-data TLV: 3413 flags = 0 IDCount = 1, IDs=5 3414 DATARAW TLV, Length = XXXX 3415 index, someidv, TLV: T=DATARAW, L = 4+strlen(namev), 3416 V = namev 3417 index, someidv, TLV: T=DATARAW, L = 4+strlen(namev), 3418 V = namev 3419 index, someidv, TLV: T=DATARAW, L = 4+strlen(namev), 3420 V = namev 3421 index, someidv, TLV: T=DATARAW, L = 4+strlen(namev), 3422 V = namev 3423 . 3424 . 3425 . 3427 15. Multiple atomic operations. 3429 16. Note: This emulates adding a new nexthop entry and then 3430 atomically updating the L3 entries pointing to an old NH to 3431 point to a new one. The assumption is both tables are in the 3432 same LFB 3434 17. Main header has atomic flag set and we are request for verbose/ 3435 full results back; Two operations on the LFB instance, both are 3436 SET operations. 3438 //Operation 1: Add a new entry to table2 index #20. 3439 OPER = SET-CREATE-TLV 3440 Path-TLV: 3441 flags = 0, IDCount = 2, IDs=4.20 3442 DATARAW TLV, V= j1value,j2value 3444 // Operation 2: Update table1 entry which 3445 // was pointing with t2 = 10 to now point to 20 3446 OPER = SET-REPLACE-TLV 3447 Path-data-TLV: 3448 flags = F_SELKEY, IDCount = 1, IDs=3 3449 KEYINFO = KEYID=1 KEY_DATA=10 3450 Path-data-TLV 3451 flags = 0 IDCount = 1, IDs=2 3452 DATARAW TLV, V= 20 3454 Result: 3455 //first operation, SET 3456 OPER = SET-RESPONSE-TLV 3457 Path-data-TLV 3458 flags = 0 IDCount = 3, IDs=4.20 3459 RESULT-TLV code = success 3460 DATARAW TLV, V = j1value,j2value 3461 // second opertion SET - assuming entry 16 was updated 3462 OPER = SET-RESPONSE-TLV 3463 Path-data TLV 3464 flags = 0 IDCount = 2, IDs=3.16 3465 Path-Data TLV 3466 flags = 0 IDCount = 1, IDs = 2 3467 SET-RESULT-TLV code = success 3468 DATARAW TLV, Length = XXXX v=20 3469 // second opertion SET 3470 OPER = SET-RESPONSE-TLV 3471 Path-data TLV 3472 flags = 0 IDCount = 1, IDs=3 3473 KEYINFO = KEYID=1 KEY_DATA=10 3474 Path-Data TLV 3475 flags = 0 IDCount = 1, IDs = 2 3476 SET-RESULT-TLV code = success 3477 DATARAW TLV, Length = XXXX v=20 3479 18. Selective setting (Example posted by Weiming). On table 4 -- 3480 for indices 1, 3, 5, 7, and 9. Replace j1 to 100, j2 to 200, j3 3481 to 300. Leave j4 as is. 3483 PER = SET-REPLACE-TLV 3484 Path-data TLV 3485 flags = 0, IDCount = 1, IDs = 6 3486 Path-data TLV 3487 flags = 0, IDCount = 1, IDs = 1 3488 Path-data TLV 3489 flags = 0, IDCount = 1, IDs = 1 3490 DATARAW TLV, Length = XXXX, V = {100} 3491 Path-data TLV 3492 flags = 0, IDCount = 1, IDs = 2 3493 DATARAW TLV, Length = XXXX, V = {200} 3494 Path-data TLV 3495 flags = 0, IDCount = 1, IDs = 3 3496 DATARAW TLV, Length = XXXX, V = {300} 3497 Path-data TLV 3498 flags = 0, IDCount = 1, IDs = 3 3499 Path-data TLV 3500 flags = 0, IDCount = 1, IDs = 1 3501 DATARAW TLV, Length = XXXX, V = {100} 3502 Path-data TLV 3503 flags = 0, IDCount = 1, IDs = 2 3504 DATARAW TLV, Length = XXXX, V = {200} 3505 Path-data TLV 3506 flags = 0, IDCount = 1, IDs = 3 3507 DATARAW TLV, Length = XXXX, V = {300} 3508 Path-data TLV 3509 flags = 0, IDCount = 1, IDs = 5 3510 Path-data TLV 3511 flags = 0, IDCount = 1, IDs = 1 3512 DATARAW TLV, Length = XXXX, V = {100} 3513 Path-data TLV 3514 flags = 0, IDCount = 1, IDs = 2 3515 DATARAW TLV, Length = XXXX, V = {200} 3516 Path-data TLV 3517 flags = 0, IDCount = 1, IDs = 3 3518 DATARAW TLV, Length = XXXX, V = {300} 3519 Path-data TLV 3520 flags = 0, IDCount = 1, IDs = 7 3521 Path-data TLV 3522 flags = 0, IDCount = 1, IDs = 1 3523 DATARAW TLV, Length = XXXX, V = {100} 3524 Path-data TLV 3525 flags = 0, IDCount = 1, IDs = 2 3526 DATARAW TLV, Length = XXXX, V = {200} 3527 Path-data TLV 3528 flags = 0, IDCount = 1, IDs = 3 3529 DATARAW TLV, Length = XXXX, V = {300} 3530 Path-data TLV 3531 flags = 0, IDCount = 1, IDs = 9 3532 Path-data TLV 3533 flags = 0, IDCount = 1, IDs = 1 3534 DATARAW TLV, Length = XXXX, V = {100} 3535 Path-data TLV 3536 flags = 0, IDCount = 1, IDs = 2 3537 DATARAW TLV, Length = XXXX, V = {200} 3538 Path-data TLV 3539 flags = 0, IDCount = 1, IDs = 3 3540 DATARAW TLV, Length = XXXX, V = {300} 3542 Non-verbose response mode shown: 3544 OPER = SET-RESPONSE-TLV 3545 Path-data TLV 3546 flags = 0, IDCount = 1, IDs = 6 3547 Path-data TLV 3548 flags = 0, IDCount = 1, IDs = 1 3549 Path-data TLV 3550 flags = 0, IDCount = 1, IDs = 1 3551 RESULT-TLV 3552 Path-data TLV 3553 flags = 0, IDCount = 1, IDs = 2 3554 RESULT-TLV 3555 Path-data TLV 3556 flags = 0, IDCount = 1, IDs = 3 3557 RESULT-TLV 3558 Path-data TLV 3559 flags = 0, IDCount = 1, IDs = 3 3560 Path-data TLV 3561 flags = 0, IDCount = 1, IDs = 1 3562 RESULT-TLV 3563 Path-data TLV 3564 flags = 0, IDCount = 1, IDs = 2 3565 RESULT-TLV 3566 Path-data TLV 3567 flags = 0, IDCount = 1, IDs = 3 3568 RESULT-TLV 3569 Path-data TLV 3570 flags = 0, IDCount = 1, IDs = 5 3571 Path-data TLV 3572 flags = 0, IDCount = 1, IDs = 1 3573 RESULT-TLV 3574 Path-data TLV 3575 flags = 0, IDCount = 1, IDs = 2 3576 RESULT-TLV 3577 Path-data TLV 3578 flags = 0, IDCount = 1, IDs = 3 3579 RESULT-TLV 3580 Path-data TLV 3581 flags = 0, IDCount = 1, IDs = 7 3582 Path-data TLV 3583 flags = 0, IDCount = 1, IDs = 1 3584 RESULT-TLV 3585 Path-data TLV 3586 flags = 0, IDCount = 1, IDs = 2 3587 RESULT-TLV 3588 Path-data TLV 3589 flags = 0, IDCount = 1, IDs = 3 3590 RESULT-TLV 3591 Path-data TLV 3592 flags = 0, IDCount = 1, IDs = 9 3593 Path-data TLV 3594 flags = 0, IDCount = 1, IDs = 1 3595 RESULT-TLV 3596 Path-data TLV 3597 flags = 0, IDCount = 1, IDs = 2 3598 RESULT-TLV 3599 Path-data TLV 3600 flags = 0, IDCount = 1, IDs = 3 3601 RESULT-TLV 3603 19. Manipulation of table of table examples. Get x1 from table10 3604 row with index 4, inside table5 entry 10 3606 operation = GET-TLV 3607 Path-data-TLV 3608 flags = 0 IDCount = 5, IDs=7.10.2.4.1 3610 Results: 3611 operation = GET-RESPONSE-TLV 3612 Path-data-TLV 3613 flags = 0 IDCount = 5, IDs=7.10.2.4.1 3614 DATARAW TLV: L=XXXX, V = {x1 value} 3616 20. From table5's row 10 table10, get X2s based on on the value of 3617 x1 equlaing 10 (recal x1 is KeyID 1) 3619 operation = GET-TLV 3620 Path-data-TLV 3621 flag = F_SELKEY, IDCount=3, IDS = 7.10.2 3622 KEYINFO TLV, KEYID = 1, KEYDATA = 10 3623 Path-data TLV 3624 IDCount = 1, IDS = 2 //select x2 3626 Results: 3627 If x1=10 was at entry 11: 3628 operation = GET-RESPONSE-TLV 3629 Path-data-TLV 3630 flag = 0, IDCount=5, IDS = 7.10.2.11 3631 Path-data TLV 3632 flags = 0 IDCount = 1, IDS = 2 3633 DATARAW TLV: L=XXXX, V = {x2 value} 3635 21. Further example of table of table 3637 Consider table 6 which is defined as: 3638 table6: type array, ID = 8 3639 elements are: 3640 p1, type u32, ID = 1 3641 p2, type array, ID = 2, array elements of type type-A 3643 type-A: 3644 a1, type u32, ID 1, 3645 a2, type array ID2 ,array elements of type type-B 3647 type-B: 3648 b1, type u32, ID 1 3649 b2, type u32, ID 2 3651 So lets say we wanted to set by replacing: 3652 table6.10.p1 to 111 3653 table6.10.p2.20.a1 to 222 3654 table6.10.p2.20.a2.30.b1 to 333 3656 in one message and one operation. 3658 There are two ways to do this: 3659 a) using nesting 3661 operation = SET-REPLACE-TLV 3662 Path-data-TLV 3663 flags = 0 IDCount = 2, IDs=6.10 3664 Path-data-TLV 3665 flags = 0, IDCount = 1, IDs=1 3666 DATARAW TLV: L=XXXX, 3667 V = {111} 3668 Path-data-TLV 3669 flags = 0 IDCount = 2, IDs=2.20 3670 Path-data-TLV 3671 flags = 0, IDCount = 1, IDs=1 3672 DATARAW TLV: L=XXXX, 3673 V = {222} 3674 Path-data TLV : 3675 flags = 0, IDCount = 3, IDs=2.30.1 3676 DATARAW TLV: L=XXXX, 3677 V = {333} 3678 Result: 3679 operation = SET-RESPONSE-TLV 3680 Path-data-TLV 3681 flags = 0 IDCount = 2, IDs=6.10 3682 Path-data-TLV 3683 flags = 0, IDCount = 1, IDs=1 3684 RESULT-TLV 3685 Path-data-TLV 3686 flags = 0 IDCount = 2, IDs=2.20 3687 Path-data-TLV 3688 flags = 0, IDCount = 1, IDs=1 3689 RESULT-TLV 3690 Path-data TLV : 3691 flags = 0, IDCount = 3, IDs=2.30.1 3692 RESULT-TLV 3693 b) using a flat path data 3694 operation = SET-REPLACE-TLV 3695 Path-data TLV : 3696 flags = 0, IDCount = 3, IDs=6.10.1 3697 DATARAW TLV: L=XXXX, 3698 V = {111} 3699 Path-data TLV : 3700 flags = 0, IDCount = 5, IDs=6.10.1.20.1 3701 DATARAW TLV: L=XXXX, 3702 V = {222} 3703 Path-data TLV : 3704 flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1 3705 DATARAW TLV: L=XXXX, 3706 V = {333} 3707 Result: 3708 operation = SET-REPLACE-TLV 3709 Path-data TLV : 3710 flags = 0, IDCount = 3, IDs=6.10.1 3711 RESULT-TLV 3712 Path-data TLV : 3714 flags = 0, IDCount = 5, IDs=6.10.1.20.1 3715 RESULT-TLV 3716 Path-data TLV : 3717 flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1 3718 RESULT-TLV 3720 22. Get a whole LFB (all its attributes etc). 3722 23. For example, at startup a CE might well want the entire FE 3723 OBJECT LFB. So, in a request targetted at class 1, instance 1, 3724 one might find: 3726 operation = GET-TLV 3727 Path-data-TLV 3728 flags = 0 IDCount = 0 3730 result: 3731 operation = GET-RESPONSE-TLV 3732 Path-data-TLV 3733 flags = 0 IDCount = 0 3734 DATARAW encoding of the FE Object LFB 3736 Appendix E. Implementation Notes 3738 E.1 TML considerations 3740 Having separated the PL from the TML layer, it became clear that the 3741 TML layer needed to understand the desires of the PL layer to service 3742 it. Example: How does the TML layer map prioritization or 3743 reliability needs of a PL message? To see the challenge involved, 3744 assume that all of the FE TML, FE PL, CE TML and CE PL are 3745 implemented by different authors probably belonging to different 3746 organizations. Three implementation alternatives were discussed. 3748 As an example, consider a TML which defines that PL messages needing 3749 reliability get sent over a TCP connection; then TML-PL interfaces 3750 are: 3752 o PL to call a special API: example send_reliable(msg) which is 3753 translated by the TML to mean send via TCP. 3755 o PL to call a generic API: example send(msg) with explicit msg 3756 flags turned to say "reliability needed" and the TML translates 3757 this to mean send via TCP. 3759 o PL sends the Forces Messages such a message is inferred to mean 3760 send via TCP by the TML. 3762 in #1 and #2 the msg includes a ForCES msg with metadata flags which 3763 ar consumed by the TML layer. 3765 #3 is a technique that will be referred as inference-by-TML 3766 technique. It simplifies the standardization effort since both #1 3767 and #2 will require standardization of an API. Two ideas discussed 3768 for TML inference of PL messages are: 3770 1. Looking at the flags in the header. 3772 2. Looking at the message type. 3774 #1 and #2 can still be used if a single organization implements both 3775 (PL and TML) layers. It is also reasonable that one organization 3776 implements the TML and provides an abstraction to another 3777 organization to implement a PL layer on. 3779 E.1.1 PL Flag inference by TML 3781 1. Reliability 3782 This could be "signalled" from the PL to the TML via the ACK 3783 flag. The message type as well could be used to indicate this. 3785 2. No reliability 3786 Could be signalled via missing ACK flag. The message type as 3787 well could be used to indicate this. 3789 3. Priorities 3790 A remapping to be defined via the FEM or the CEM interface 3791 depending on the number of TML priorities available. 3793 4. Addressing 3794 This is TML specific. For example a TML that is capable of 3795 multicast transport may map a multicast PL ID to a multicast 3796 transport address. 3798 5. Event notifications 3799 The TML must be able to send to the PL notifications. 3801 1. The TML should be able to send Transport level congestion 3802 notifications to the PL. 3804 2. Link events for HA purposes if configuration requires it 3806 3. Events that will trigger PL layer events from the TML. 3807 As an example, an HA event at the TML layer like a failure of 3808 CE detected at TML on the FE may belong to this. In this 3809 case, a PL event msg will be triggered and sent to CE. 3811 4. Events that are intrinsic to the same CE or FE a TML is 3812 located. These will not trigger any PL msg, instead, they 3813 just act as notification to PL core (FE object). The 3814 congestion event generated at the transmission source side 3815 may belong to this, because it usually only needs to tell the 3816 upper PL at the same side rather than the opposite side that 3817 congestion has happened along the path. E.g., a congestion 3818 event at CE TML layer only need to tell CE PL of this, rather 3819 than the opposite FE via a PL msg. 3821 E.1.2 Message type inference to Mapping at the TML 3823 In this case one would define the desires of the different message 3824 types and what they expect from the TML. For example: 3826 1. Association Setup, Teardown, Config, Query the PL will expect the 3827 following services from TML: Reliable delivery and highest 3828 prioritization. 3830 2. Packet Redirect, HB Message Types, and Event Reports the PL will 3831 require the following services from TML: Medium Prioritization, 3832 and notifications when excessive losses are reached. 3834 Appendix F. changes between -02 and -03 3836 1. Remove most all editorial notes and replaced them with entries in 3837 tracker. 3839 2. Marked TBD with tracker issue number 3841 3. In section on config message replaced GET in the example figures 3842 to SET 3844 4. ISSUE: 12 - replaced Command with Message type in Common Header 3846 5. ISSUE: 12 - in Data Packing Rules replaced 'sans' with 'without 3847 the' 3849 6. Removed an uncountably large multitude of tabs that were making 3850 xml2rfc-1.29 choke 3852 7. fixed many nits 3854 Appendix G. Changes between -01 and -02 3856 1. Renamed definitions.xml to Definitions.xml 3858 2. Added Alistair Munro to acks list. 3860 3. path-data additions + full BNF conformant to RFC 2234 3862 4. Appendix C with examples. #3 and #4 are the biggest changes 3863 incorporate many many days of discussion. 3865 5. appendix with beginings of FE protocol LFB xml. The FE Object 3866 is referenced as being in the Model draft 3868 6. Some cosmetic things like: 3870 1. For readability, introducing section 'protocol construction' 3871 which now encapsulates 'Protocol Messages' (which used to be 3872 a top section) 3874 2. A new subsection "protocol grammar' goes underneath the same 3875 section. 3877 3. added TLV definition subsection 3879 4. Many new "editorial notes" 3881 7. Closure of all but one outstanding issue from the tracker. 3883 8. Any other cosmetic changes posted (Hormuzd, David, Robert, 3884 Avri). 3886 9. Rearranged text a little to introduce new sections to make text 3887 more readable 3889 10. Rewrote the atomicity section (still under construction input 3890 text on ACID from Robert and Alistair) 3892 11. fixed up the model reference to have all authors and added acid 3893 reference 3895 12. Weiming's updates to query and event msgs to add path-data. 3897 Appendix H. Changes between -00 and -01 3899 1. Major Protocol changes 3901 * Restructured message format to apply operation to LFB as 3902 opposed to having operation be the primary organizing 3903 principle 3905 * Worked with model team to bring the draft into harmony with 3906 their model approach 3908 2. Document changes 3910 * Replaced FE protocol Object and FE Object sections with 3911 combined section on FE, CE and FE protocol LFBs 3913 * Removed minor version id 3915 * Added Header flags 3917 * Added BNF description of message structure 3919 * Added tree structure description of PDUs 3921 * Added section on each type of LFB 3923 * Added structural description of each message 3925 * Moved query messages section to come after config message 3926 section 3928 * Replace state maintenance section 3930 * Added section with tables showing the operations relevant to 3931 particular messages 3933 * Reworked HA section 3935 * Many spelling and grammatical corrections 3937 Intellectual Property Statement 3939 The IETF takes no position regarding the validity or scope of any 3940 Intellectual Property Rights or other rights that might be claimed to 3941 pertain to the implementation or use of the technology described in 3942 this document or the extent to which any license under such rights 3943 might or might not be available; nor does it represent that it has 3944 made any independent effort to identify any such rights. Information 3945 on the procedures with respect to rights in RFC documents can be 3946 found in BCP 78 and BCP 79. 3948 Copies of IPR disclosures made to the IETF Secretariat and any 3949 assurances of licenses to be made available, or the result of an 3950 attempt made to obtain a general license or permission for the use of 3951 such proprietary rights by implementers or users of this 3952 specification can be obtained from the IETF on-line IPR repository at 3953 http://www.ietf.org/ipr. 3955 The IETF invites any interested party to bring to its attention any 3956 copyrights, patents or patent applications, or other proprietary 3957 rights that may cover technology that may be required to implement 3958 this standard. Please address the information to the IETF at 3959 ietf-ipr@ietf.org. 3961 The IETF has been notified of intellectual property rights claimed in 3962 regard to some or all of the specification contained in this 3963 document. For more information consult the online list of claimed 3964 rights. 3966 Disclaimer of Validity 3968 This document and the information contained herein are provided on an 3969 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3970 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3971 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3972 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3973 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3974 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3976 Copyright Statement 3978 Copyright (C) The Internet Society (2005). This document is subject 3979 to the rights, licenses and restrictions contained in BCP 78, and 3980 except as set forth therein, the authors retain all their rights. 3982 Acknowledgment 3984 Funding for the RFC Editor function is currently provided by the 3985 Internet Society.