idnits 2.17.1 draft-ietf-forces-protocol-02.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.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 3859. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 3836. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 3843. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 3849. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** 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. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 191 instances of too long lines in the document, the longest one being 41 characters in excess of 72. ** There are 51 instances of lines with control characters in the document. == 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 637: '... ForCES transactions MUST support ACIDity [ACID], defined as:...' RFC 2119 keyword, line 654: '...or more messages MUST have ACID proper...' RFC 2119 keyword, line 692: '... records of the transaction MUST reply...' RFC 2119 keyword, line 894: '... field. Senders SHOULD set it to zero...' RFC 2119 keyword, line 967: '...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 505 has weird spacing: '...ing are scena...' == Line 1248 has weird spacing: '...is used with ...' == Line 2080 has weird spacing: '...data is a 'PA...' == Line 2237 has weird spacing: '...data is a 'PA...' == Line 3142 has weird spacing: '...j2value entri...' == (1 more instance...) -- 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 (February 20, 2005) is 6997 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 1081, but not defined == Missing Reference: 'SELECTOR' is mentioned on line 1082, but not defined == Missing Reference: 'TBD' is mentioned on line 2427, but not defined -- Looks like a reference, but probably isn't: '101' on line 3034 -- Looks like a reference, but probably isn't: '200' on line 3034 == Unused Reference: 'RFC2629' is defined on line 2844, 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: 11 errors (**), 0 flaws (~~), 14 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group A. Doria (co-editor) 2 Internet-Draft ETRI 3 Expires: August 24, 2005 February 20, 2005 5 ForCES Protocol Specification 6 draft-ietf-forces-protocol-02.txt 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of Section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on August 24, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This specification documents the Forwarding and Control Element 42 Separation protocol. This protocol is designed to be used between a 43 Control Element and a Forwarding Element in a Routing Network 44 Element. 46 Authors 47 The participants in the ForCES Protocol Team, co-authors and 48 co-editors, of this draft, are: 50 Ligang Dong (Zhejiang Gongshang University), Avri Doria (ETRI), Ram 51 Gopal (Nokia), Robert Haas (IBM), Jamal Hadi Salim (Znyx), Hormuzd M 52 Khosravi (Intel), and Weiming Wang (Zhejiang Gongshang University). 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 57 1.1 Sections of this document . . . . . . . . . . . . . . . . 4 58 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 59 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 60 3.1 Protocol Framework . . . . . . . . . . . . . . . . . . . . 8 61 3.1.1 The PL layer . . . . . . . . . . . . . . . . . . . . . 10 62 3.1.2 The TML layer . . . . . . . . . . . . . . . . . . . . 11 63 3.1.3 The FEM/CEM Interface . . . . . . . . . . . . . . . . 11 64 3.2 ForCES Protocol Phases . . . . . . . . . . . . . . . . . . 12 65 3.2.1 Pre-association . . . . . . . . . . . . . . . . . . . 12 66 3.2.2 Post-association . . . . . . . . . . . . . . . . . . . 13 67 3.3 Protocol Mechanisms . . . . . . . . . . . . . . . . . . . 14 68 3.3.1 Transactions, Atomicity, Execution and Responses . . . 14 69 3.3.2 FE, CE, and FE protocol LFBs . . . . . . . . . . . . . 17 70 3.3.3 Scaling by Concurrency . . . . . . . . . . . . . . . . 18 71 4. TML Requirements . . . . . . . . . . . . . . . . . . . . . . . 19 72 4.1 TML Parameterization . . . . . . . . . . . . . . . . . . . 20 73 5. Message encapsulation . . . . . . . . . . . . . . . . . . . . 21 74 5.1 Common Header . . . . . . . . . . . . . . . . . . . . . . 21 75 5.2 Type Length Value . . . . . . . . . . . . . . . . . . . . 24 76 5.2.1 Nested TLVs . . . . . . . . . . . . . . . . . . . . . 24 77 5.2.2 Scope of the T in TLV . . . . . . . . . . . . . . . . 24 78 6. Protocol Construction . . . . . . . . . . . . . . . . . . . . 26 79 6.1 Protocol Grammar . . . . . . . . . . . . . . . . . . . . . 26 80 6.1.1 Protocol BNF . . . . . . . . . . . . . . . . . . . . . 26 81 6.1.2 Protocol Visualization . . . . . . . . . . . . . . . . 30 82 6.2 Core ForCES LFBs . . . . . . . . . . . . . . . . . . . . . 33 83 6.2.1 FE Protocol LFB . . . . . . . . . . . . . . . . . . . 33 84 6.2.2 FE Object LFB . . . . . . . . . . . . . . . . . . . . 34 85 6.2.3 CE LFB . . . . . . . . . . . . . . . . . . . . . . . . 35 86 6.3 Semantics of message Direction . . . . . . . . . . . . . . 35 87 6.4 Association Messages . . . . . . . . . . . . . . . . . . . 35 88 6.4.1 Association Setup Message . . . . . . . . . . . . . . 36 89 6.4.2 Association Setup Response Message . . . . . . . . . . 38 90 6.4.3 Association Teardown Message . . . . . . . . . . . . . 40 91 6.5 Configuration Messages . . . . . . . . . . . . . . . . . . 41 92 6.5.1 Config Message . . . . . . . . . . . . . . . . . . . . 42 93 6.5.2 Config Response Message . . . . . . . . . . . . . . . 43 94 6.6 Query and Query Response Messages . . . . . . . . . . . . 45 95 6.6.1 Query Message . . . . . . . . . . . . . . . . . . . . 45 96 6.6.2 Query Response Message . . . . . . . . . . . . . . . . 47 97 6.7 Event Notification and Response Messages . . . . . . . . . 48 98 6.7.1 Event Notification Message . . . . . . . . . . . . . . 49 99 6.7.2 Event Notification Response Message . . . . . . . . . 51 100 6.8 Packet Redirect Message . . . . . . . . . . . . . . . . . 52 101 6.9 Heartbeat Message . . . . . . . . . . . . . . . . . . . . 56 102 6.10 Operation Summary . . . . . . . . . . . . . . . . . . . . 57 103 7. Protocol Scenarios . . . . . . . . . . . . . . . . . . . . . . 58 104 7.1 Association Setup state . . . . . . . . . . . . . . . . . 58 105 7.2 Association Established state or Steady State . . . . . . 59 106 8. High Availability Support . . . . . . . . . . . . . . . . . . 62 107 8.1 Responsibilities for HA . . . . . . . . . . . . . . . . . 64 108 9. Security Considerations . . . . . . . . . . . . . . . . . . . 65 109 9.1 No Security . . . . . . . . . . . . . . . . . . . . . . . 65 110 9.1.1 Endpoint Authentication . . . . . . . . . . . . . . . 65 111 9.1.2 Message authentication . . . . . . . . . . . . . . . . 66 112 9.2 ForCES PL and TML security service . . . . . . . . . . . . 66 113 9.2.1 Endpoint authentication service . . . . . . . . . . . 66 114 9.2.2 Message authentication service . . . . . . . . . . . . 66 115 9.2.3 Confidentiality service . . . . . . . . . . . . . . . 67 116 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 68 117 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 69 118 11.1 Normative References . . . . . . . . . . . . . . . . . . . 69 119 11.2 Informational References . . . . . . . . . . . . . . . . . 69 120 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 69 121 A. Individual Authors/Editors Contact . . . . . . . . . . . . . . 70 122 B. IANA considerations . . . . . . . . . . . . . . . . . . . . . 72 123 C. Forces Protocol LFB schema . . . . . . . . . . . . . . . . . . 73 124 C.1 Events . . . . . . . . . . . . . . . . . . . . . . . . . . 74 125 C.2 Capabilities . . . . . . . . . . . . . . . . . . . . . . . 74 126 C.3 Attributes . . . . . . . . . . . . . . . . . . . . . . . . 74 127 C.3.1 HBI . . . . . . . . . . . . . . . . . . . . . . . . . 74 128 C.3.2 HBDI . . . . . . . . . . . . . . . . . . . . . . . . . 75 129 C.3.3 CurrentRunningVersion . . . . . . . . . . . . . . . . 75 130 D. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 76 131 E. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 90 132 E.1 TML considerations . . . . . . . . . . . . . . . . . . . . 90 133 E.1.1 PL Flag inference by TML . . . . . . . . . . . . . . . 90 134 E.1.2 Message type inference to Mapping at the TML . . . . . 91 135 F. Changes between -01 and -02 . . . . . . . . . . . . . . . . . 92 136 G. Changes between -00 and -01 . . . . . . . . . . . . . . . . . 93 137 Intellectual Property and Copyright Statements . . . . . . . . 94 139 1. Introduction 141 This specification provides a draft definition of an IP-based 142 protocol for Control Element control of an Forwarding Element. The 143 protocol is a TLV based protocol that include commands for transport 144 of LFB information as well as TLVs for association, configuration, 145 status, and events. 147 This specification does not specify a transport mechanism for 148 messages, but does include a discussion of the services that must be 149 provided by the transport interface. 151 1.1 Sections of this document 153 Section 2 provides a glossary of terminology used in the 154 specification. 156 Section 3 provides an overview of the protocol including a discussion 157 on the protocol framework, descriptions of the protocol layer (PL) 158 and a transport mapping layer (TML), as well as of the ForCES 159 protocol mechanisms. 161 While this document does not define the TML, Section 4 details the 162 services that the TML must provide. 164 The Forces protocol is defined to have a common header for all other 165 message types. The header is defined in Section 5.1, while the 166 protocol messages are defined in Section 6. 168 Section 7 describes several Protocol Scenarios and includes message 169 exchange descriptions. 171 Section 8 describes mechanism in the protocol to support high 172 availability mechanisms including redundancy and fail over. 173 Section 9 defines the security mechanisms provided by the PL and TML. 175 2. Definitions 177 This document follows the terminology defined by the ForCES 178 Requirements in [RFC3654] and by the ForCES framework in [RFC3746]. 179 This document also uses the terminology defined by ForCES FE model in 180 [FE-MODEL]. We copy the definitions of some of the terminology as 181 indicated below: 183 Addressable Entity (AE) - A physical device that is directly 184 addressable given some interconnect technology. For example, on IP 185 networks, it is a device to which we can communicate using an IP 186 address; and on a switch fabric, it is a device to which we can 187 communicate using a switch fabric port number. 189 Forwarding Element (FE) - A logical entity that implements the ForCES 190 protocol. FEs use the underlying hardware to provide per-packet 191 processing and handling as directed/controlled by a CE via the ForCES 192 protocol. 194 Control Element (CE) - A logical entity that implements the ForCES 195 protocol and uses it to instruct one or more FEs how to process 196 packets. CEs handle functionality such as the execution of control 197 and signaling protocols. 199 Pre-association Phase - The period of time during which a FE Manager 200 (see below) and a CE Manager (see below) are determining which FE and 201 CE should be part of the same network element. 203 Post-association Phase - The period of time during which a FE does 204 know which CE is to control it and vice versa, including the time 205 during which the CE and FE are establishing communication with one 206 another. 208 FE Model - A model that describes the logical processing functions 209 of a FE. 211 FE Manager (FEM) - A logical entity that operates in the 212 pre-association phase and is responsible for determining to which 213 CE(s) a FE should communicate. This process is called CE discovery 214 and may involve the FE manager learning the capabilities of available 215 CEs. A FE manager may use anything from a static configuration to a 216 pre-association phase protocol (see below) to determine which CE(s) 217 to use. Being a logical entity, a FE manager might be physically 218 combined with any of the other logical entities such as FEs. 220 CE Manager (CEM) - A logical entity that operates in the 221 pre-association phase and is responsible for determining to which 222 FE(s) a CE should communicate. This process is called FE discovery 223 and may involve the CE manager learning the capabilities of available 224 FEs. A CE manager may use anything from a static configuration to a 225 pre-association phase protocol (see below) to determine which FE to 226 use. Being a logical entity, a CE manager might be physically 227 combined with any of the other logical entities such as CEs. 229 ForCES Network Element (NE) - An entity composed of one or more CEs 230 and one or more FEs. To entities outside a NE, the NE represents a 231 single point of management. Similarly, a NE usually hides its 232 internal organization from external entities. 234 High Touch Capability - This term will be used to apply to the 235 capabilities found in some forwarders to take action on the contents 236 or headers of a packet based on content other than what is found in 237 the IP header. Examples of these capabilities include NAT-PT, 238 firewall, and L7 content recognition. 240 Datapath -- A conceptual path taken by packets within the forwarding 241 plane inside an FE. 243 LFB (Logical Function Block) type -- A template representing a 244 fine-grained, logically separable and well-defined packet processing 245 operation in the datapath. LFB types are the basic building blocks 246 of the FE model. 248 LFB (Logical Function Block) Instance -- As a packet flows through an 249 FE along a datapath, it flows through one or multiple LFB instances, 250 with each implementing an instance of a certain LFB type. There may 251 be multiple instances of the same LFB in an FE's datapath. Note that 252 we often refer to LFBs without distinguishing between LFB type and 253 LFB instance when we believe the implied reference is obvious for the 254 given context. 256 LFB Metadata -- Metadata is used to communicate per-packet state from 257 one LFB to another, but is not sent across the network. The FE model 258 defines how such metadata is identified, produced and consumed by the 259 LFBs, but not how metadata is encoded within an implementation. 261 LFB Attribute -- Operational parameters of the LFBs that must be 262 visible to the CEs are conceptualized in the FE model as the LFB 263 attributes. The LFB attributes include, for example, flags, single 264 parameter arguments, complex arguments, and tables that the CE can 265 read or/and write via the ForCES protocol (see below). 267 LFB Topology -- Representation of how the LFB instances are logically 268 interconnected and placed along the datapath within one FE. 269 Sometimes it is also called intra-FE topology, to be distinguished 270 from inter-FE topology. 272 FE Topology -- A representation of how the multiple FEs within a 273 single NE are interconnected. Sometimes this is called inter-FE 274 topology, to be distinguished from intra-FE topology (i.e., LFB 275 topology). 277 Inter-FE Topology -- See FE Topology. 279 Intra-FE Topology -- See LFB Topology. 281 Following terminologies are defined by this document: 283 ForCES Protocol - While there may be multiple protocols used within 284 the overall ForCES architecture, the term "ForCES protocol" refers 285 only to the protocol used at the Fp reference point in the ForCES 286 Framework in RFC3746 [RFC3746]. This protocol does not apply to 287 CE-to-CE communication, FE-to-FE communication, or to communication 288 between FE and CE managers. Basically, the ForCES protocol works in 289 a master-slave mode in which FEs are slaves and CEs are masters. 290 This document defines the specifications for this ForCES protocol. 292 ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol 293 architecture that defines the ForCES protocol messages, the protocol 294 state transfer scheme, as well as the ForCES protocol architecture 295 itself (including requirements of ForCES TML (see below)). 296 Specifications of ForCES PL are defined by this document. 298 ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in 299 ForCES protocol architecture that specifically addresses the protocol 300 message transportation issues, such as how the protocol messages are 301 mapped to different transport media (like TCP, IP, ATM, Ethernet, 302 etc), and how to achieve and implement reliability, multicast, 303 ordering, etc. The ForCES TML is specifically addressed in a 304 separate ForCES TML Specification document. 306 3. Overview 308 The reader is referred to the Framework document [RFC3746], and in 309 particular sections 3 and 4, for an architectural overview and an 310 explanation of how the ForCES protocol fits in. There may be some 311 content overlap between the framework document and this section in 312 order to provide clarity. 314 3.1 Protocol Framework 316 Figure 1 below is reproduced from the Framework document for clarity. 317 It shows a NE with two CEs and two FEs. 319 --------------------------------------- 320 | ForCES Network Element | 321 -------------- Fc | -------------- -------------- | 322 | CE Manager |---------+-| CE 1 |------| CE 2 | | 323 -------------- | | | Fr | | | 324 | | -------------- -------------- | 325 | Fl | | | Fp / | 326 | | Fp| |----------| / | 327 | | | |/ | 328 | | | | | 329 | | | Fp /|----| | 330 | | | /--------/ | | 331 -------------- Ff | -------------- -------------- | 332 | FE Manager |---------+-| FE 1 | Fi | FE 2 | | 333 -------------- | | |------| | | 334 | -------------- -------------- | 335 | | | | | | | | | | 336 ----+--+--+--+----------+--+--+--+----- 337 | | | | | | | | 338 | | | | | | | | 339 Fi/f Fi/f 341 Fp: CE-FE interface 342 Fi: FE-FE interface 343 Fr: CE-CE interface 344 Fc: Interface between the CE Manager and a CE 345 Ff: Interface between the FE Manager and an FE 346 Fl: Interface between the CE Manager and the FE Manager 347 Fi/f: FE external interface 349 Figure 1: ForCES Architectural Diagram 351 The ForCES protocol domain is found in the Fp Reference Point. The 352 Protocol Element configuration reference points, Fc and Ff also play 353 a role in the booting up of the Forces Protocol. The protocol 354 element configuration is out of scope of the ForCES protocol but is 355 touched on in this document since it is an integral part of the 356 protocol pre-association phase. 358 Figure 2 below shows further breakdown of the Fp interface by example 359 of a MPLS QoS enabled Network Element. 361 ------------------------------------------------- 362 | | | | | | | 363 |OSPF |RIP |BGP |RSVP |LDP |. . . | 364 | | | | | | | 365 ------------------------------------------------- 366 | ForCES Interface | 367 ------------------------------------------------- 368 ^ ^ 369 | | 370 ForCES | |data 371 control | |packets 372 messages| |(e.g., routing packets) 373 | | 374 v v 375 ------------------------------------------------- 376 | ForCES Interface | 377 ------------------------------------------------- 378 | | | | | | | 379 |LPM Fwd|Meter |Shaper |MPLS |Classi-|. . . | 380 | | | | |fier | | 381 ------------------------------------------------- 383 Figure 2: Examples of CE and FE functions 385 The ForCES Interface shown in Figure 2 constitutes two pieces: the PL 386 and TML layer. 388 This is depicted in Figure 3 below. 390 +------------------------------------------------ 391 | CE PL layer | 392 +------------------------------------------------ 393 | CE TML layer | 394 +------------------------------------------------ 395 ^ 396 | 397 ForCES | (i.e Forces data + control 398 PL | packets ) 399 messages | 400 over | 401 specific | 402 TML | 403 encaps | 404 and | 405 transport | 406 | 407 v 408 +------------------------------------------------ 409 | FE TML layer | 410 +------------------------------------------------ 411 | FE PL layer | 412 +------------------------------------------------ 414 Figure 3: ForCES Interface 416 The PL layer is in fact the ForCES protocol. Its semantics and 417 message layout are defined in this document. The TML Layer is 418 necessary to connect two ForCES PL layers as shown in Figure 3 above. 419 The TML is out of scope for this document but is within scope of 420 ForCES. This document defines requirements the PL needs the TML to 421 meet. 423 Both the PL and the TML layers are standardized by the IETF. While 424 only one PL layer is defined, different TMLs are expected to be 425 standardized. To interoperate the TML layer at the CE and FE are 426 expected to conform to the same definition. 428 On transmit, the PL layer delivers its messages to the TML layer. 429 The TML layer delivers the message to the destination TML layer(s). 430 On receive, the TML delivers the message to its destination PL 431 layer(s). 433 3.1.1 The PL layer 435 The PL is common to all implementations of ForCES and is standardized 436 by the IETF as defined in this document. The PL layer is responsible 437 for associating an FE or CE to an NE. It is also responsible for 438 tearing down such associations. An FE uses the PL layer to throw 439 various subscribed-to events to the CE PL layer as well as respond to 440 various status requests issued from the CE PL. The CE configures 441 both the FE and associated LFBs attributes using the PL layer. In 442 addition the CE may send various requests to the FE to activate or 443 deactivate it, reconfigure its HA parametrization, subscribe to 444 specific events etc. More details in Section 6. 446 3.1.2 The TML layer 448 The TML layer is essentially responsible for transport of the PL 449 layer messages. The TML is where the issues of how to achieve 450 transport level reliability, congestion control, multicast, ordering, 451 etc are handled. It is expected more than one TML will be 452 standardized. The different TMLs each could implement things 453 differently based on capabilities of underlying media and transport. 454 However, since each TML is standardized, interoperability is 455 guaranteed as long as both endpoints support the same TML. All 456 ForCES Protocol Layer implementations should be portable across all 457 TMLs, because all TMLs have the same top edge semantics as defined in 458 this document. 460 3.1.3 The FEM/CEM Interface 462 The FEM and CEM components, although valuable in the setup and 463 configurations of both the PL and TML layers, are out of scope of the 464 ForCES protocol. The best way to think of them are as 465 configurations/parameterizations for the PL and TML before they 466 become active (or even at runtime based on implementation). In the 467 simplest case, the FE or CE read a static configuration file which 468 they use as the FEM/CEM interface. RFC 3746 has a lot more detailed 469 descriptions on how the FEM and CEM could be used. We discuss the 470 pre-association phase where the CEM and FEM play briefly in section 471 Section 3.2.1. 473 An example of typical things FEM/CEM would configure would be TML 474 specific parameterizations such as: 475 a. how the TML connection should happen (example what IP addresses 476 to use, transport modes etc); 477 b. the ID for the FE or CE would also be issued at this point. 478 c. Security parameterization such as keys etc. 479 d. Connection association parameters 481 Example "send up to 3 association messages each 1 second apart" Vs " 482 send up to 4 association messages with increasing exponential 483 timeout". 485 3.2 ForCES Protocol Phases 487 ForCES, in relation to NEs, involves two phases: the Pre-Association 488 phase where configuration/initialization/bootup of the TML and PL 489 layer happens, and the association phase where the ForCES protocol 490 operates. 492 3.2.1 Pre-association 494 The ForCES interface is configured during the pre-association phase. 495 In a simple setup, the configuration is static and is read from a 496 saved config file. All the parameters for the association phase are 497 well known after the pre-association phase is complete. A protocol 498 such as DHCP may be used to retrieve the config parameters instead of 499 reading them from a static config file. Note, this will still be 500 considered static pre-association. Dynamic configuration may also 501 happen using the Fc, Ff and Fl reference points. Vendors may use 502 their own proprietary service discovery protocol to pass the 503 parameters. 505 The following are scenarios reproduced from the Framework Document 506 to show a pre-association example. 508 <----Ff ref pt---> <--Fc ref pt-------> 509 FE Manager FE CE Manager CE 510 | | | | 511 | | | | 512 (security exchange) (security exchange) 513 1|<------------>| authentication 1|<----------->|authentication 514 | | | | 515 (FE ID, attributes) (CE ID, attributes) 516 2|<-------------| request 2|<------------|request 517 | | | | 518 3|------------->| response 3|------------>|response 519 (corresponding CE ID) (corresponding FE ID) 520 | | | | 521 | | | | 523 Figure 4: Examples of a message exchange over the Ff and Fc reference 524 points 526 <-----------Fl ref pt--------------> | 528 FE Manager FE CE Manager CE 529 | | | | 530 | | | | 531 (security exchange) | | 532 1|<------------------------------>| | 533 | | | | 534 (a list of CEs and their attributes) | 535 2|<-------------------------------| | 536 | | | | 537 (a list of FEs and their attributes) | 538 3|------------------------------->| | 539 | | | | 540 | | | | 542 Figure 5: An example of a message exchange over the Fl reference 543 point 545 Before the transition to the association phase, the FEM will have 546 established contact with the appropriate CEM component. 547 Initialization of the ForCES interface will be completed, and 548 authentication as well as capability discovery may be complete as 549 well. Both the FE and CE would have the necessary information for 550 connecting to each other for configuration, accounting, 551 identification and authentication purposes. Both sides also would 552 have all the necessary protocol parameters such as timers, etc. The 553 Fl reference point may continue to operate during the association 554 phase and may be used to force a disassociation of an FE or CE. 555 Because the pre-association phase is out of scope, these details are 556 not discussed any further in this specification. The reader is 557 referred to the framework document [RFC3746] for more detailed 558 discussion. 560 3.2.2 Post-association 562 In this phase, the FE and CE components communicate with each other 563 using the ForCES protocol (PL over TML) as defined in this document. 564 There are three sub-phases: 565 o Association setup state 566 o Established State 567 o Association teardown state. 569 3.2.2.1 Association setup state 571 The FE attempts to join the NE. The FE may be rejected or accepted. 572 Once granted access into the NE, capabilities exchange happens with 573 the CE querying the FE. Once the CE has the FE capability 574 information, the CE can offer an initial configuration (possibly to 575 restore state) and can query certain attributes within either an LFB 576 or the FE itself. 578 More details are provided in the protocol scenarios section. 580 On successful completion of this state, the FE joins the NE and is 581 moved to the Established State. 583 3.2.2.2 Association Established state 585 In this state the FE is continuously updated or queried. The FE may 586 also send asynchronous event notifications to the CE or synchronous 587 heartbeat notifications. This continues until a termination is 588 initiated by either the CE or the FE. 590 Refer to section on protocol scenarios Section 7 for more details. 592 3.3 Protocol Mechanisms 594 Various semantics are exposed to the protocol users via the PL header 595 including: Transaction capabilities, atomicity of transactions, two 596 phase commits, batching/parallelization, High Availability and 597 failover as well as command windows. 599 3.3.1 Transactions, Atomicity, Execution and Responses 601 In the master-slave relationship the CE instructs one or more FEs on 602 how to execute operations and how to report back the results. 604 This section details the different modes of execution that a CE can 605 order the FE(s) to perform in Section 3.3.1.1. It also describes the 606 different modes a CE can ask the FE(s) to format the responses back 607 after processing the operations requested in Section 3.3.1.2. 609 3.3.1.1 Execution 611 There are two schools of thoughts which are being tossed around at 612 the moment on Forces operations from the CE to the FE. We try to 613 support both and leave the details to implementation (the 614 intelligence is at the CE). 616 1. The CE knows exact details about the resources at the FE (memory, 617 table sizes, etc). When it says "SET" it knows that would work 618 etc. In this scenario, it is contended by the proponents of this 619 optimization that when a CE decides to send a command to an FE it 620 will work 100%. In other words, remote operations without any 621 transactional properties (given the CE computes the success of 622 the tranaaction). 623 2. The classical Two-phase-commit(2PC)[REference to be added here] 624 scheme; undo/rollback when things go wrong. undoing is initiated 625 by the CE after an error response from any one FE being 626 synchronized is received. 628 There are 3 execution modes that could be requested for operations 629 spanning on one or more LFB selectors: 631 Transactional all-or-none. 632 Any-of-N independent operations. 633 go-to-N loose transaction. 635 3.3.1.1.1 Requirements for ForCES Transactions 637 ForCES transactions MUST support ACIDity [ACID], defined as: 639 o *Atomicity*. In a transaction involving two or more discrete 640 pieces of information, either all of the pieces are committed or 641 none are. 642 o *Consistency*. A transaction either creates a new and valid state 643 of data, or, if any failure occurs, returns all data to its state 644 before the transaction was started. 645 o *Isolation*. A transaction in process and not yet committed must 646 remain isolated from any other transaction. 647 o *Durability*. Committed data is saved by the system such that, 648 even in the event of a failure and system restart, the data is 649 available in its correct state. 651 3.3.1.1.1.1 Transaction definition 653 We define a transaction as a collection of one or more ForCES 654 operations within one or more messages MUST have ACID properties. 656 3.3.1.1.1.2 Transaction protocol 658 A 2PC starts with a START | ATOMIC flag on its first message of a 659 transaction. A transaction may span multiple messages. It is up to 660 the CE to keep track of the different seq #s making up a transaction. 661 This may then be followed by more messages which are part of the same 662 atomic transaction. 664 Any failure notified by the FE causes the CE to execute an ABORT to 665 all FEs involved in the transaction, rolling back all previously 666 executed operations in the transaction. 668 The transaction commitment phase is signalled by an empty DONE msg 669 type. 671 TBD: We may need an ABORT message(used for rollback purposes) or 672 maybe a DONE with an ABORT flag to undo will suffice. 674 3.3.1.1.1.3 Recovery 676 Any of the participating FEs, or the CE, or the associations between 677 them, may fail after the DONE message has left the CE and before it 678 has received all the responses, (possibly the DONE never reached the 679 FEs). At this point it is known that none of the operations failed 680 but it is presumed that the data has not yet been made durable by the 681 FEs. The means of detecting such failures may include loss of 682 heartbeat (within the scope of ForCES) or mechanisms outside the 683 scope of ForCES. When the associations are re-established, the CE 684 will discover a transaction in an intermediate state. Some FEs will 685 have made the data durable and closed the transaction; others may 686 have failed while doing so, and may, or may not, still have that 687 data. At this point the transaction enters the recovery phase. 689 The CE re-issues an empty DONE message to all FEs involved in the 690 transaction. Those that completed the transaction confirm this to 691 the CE. Those that did not, commit the data and confirm this to the 692 CE. An FE that has lost all records of the transaction MUST reply 693 with status UNKNOWN and the actions subsequently taken by the CE are 694 implementation dependent. 696 This requires knowledge at both the CE and FE; not sure how to signal 697 it. Global flags: ATOMIC, START, ABORT? (used by 2PC) New msg type: 698 DONE, ABORT?(used by 2PC) 700 3.3.1.1.2 one-of-N independent operations 702 In which several independent operations are targeted at one or more 703 LFB selectors. Execution continues at the FE when one or more 704 operations fail. This mode is signalled by a missing ATOMIC flag. 706 3.3.1.1.3 go-to-N loose transaction 708 In which all operations are executed on FE sequentially until first 709 failure. The rest of the operations are not executed but everything 710 upto failed is not undone unlike #1. flag: GOTON (global) 712 3.3.1.1.4 Relation to Multipart messages 713 Multipart flags apply. I.e all messages in a transaction except 714 for the last have a MULTIPART flag on. 715 There has to be consistency across the multi parts of the 716 messages. In other words the first message starting with mode #1 717 above, implies the rest do. Any inconsitency implies a cancelled 718 transaction in which all messages are dropped and the sender 719 NACKED. 721 3.3.1.2 Response formating 723 Editorial Note: This is still under discussion and ties into the 724 RESULT TLV discussed in Section 6.1. 726 3.3.2 FE, CE, and FE protocol LFBs 728 All PL messages follow the LFB structure as this provides more 729 flexibility for future enhancements. This means maintanance and 730 configurability of FEs, NE, as well as the protocol require a fit in 731 the LFB architecture. For this reason special LFBs are created to 732 accomodate this need. 734 In addition, this shows how the ForCES protocol itself can be 735 controlled by the very same type of structures (LFBs) it uses to 736 control functions such as IP forwarding, filtering, etc. 738 To achieve this, the following LFBs are used: 739 o FE Protocol LFB 740 o FE LFB 741 o CE LFB 742 These LFBs are detailed in Section 6.2. A short description is 743 provided here: 744 o The FE Protocol LFB is a logical entity in each FE that is used to 745 control the ForCES protocol. The CE operates on this LFB to 746 subscribe or unsubscribe to Heartbeat messages, define the 747 Heartbeat interval, or to discover which ForCES protocol version 748 is supported and which TMLs the FE supports. The FE Protocol LFB 749 also contains the various ForCES ID to be used: unicast IDs a 750 table of the PL multicast IDs the FE must be listening to. [TBD: 751 do we need a CE Protocol LFB?] 752 o The FE LFB (referred to as "FE attributes" in the model draft) 753 should not be confused with the FE Protocol Object. The FE LFB is 754 a logical entity in each FE and contains attributes relative to 755 the FE itself, and not to the operation of the ForCES protocol 756 between the CE and the FE. Such attributes can be FEState (refer 757 to model draft), vendor, etc. The FE LFB contains in particular a 758 table that maps a virtual LFB Instance ID to one or more Instance 759 IDs of LFBs in the FE. 760 o The CE LFB is the counterpart of the FE LFB. The CE LFB is a 761 logical entity in each CE and contains attributes relative to the 762 CE itself, and not to the operation of the ForCES protocol between 763 the CE and the FE. This LFB can be used to convey event 764 notifications from a CE to FEs. Some events may be sent by the CE 765 without prior subscription by the FEs. 767 3.3.3 Scaling by Concurrency 769 It is desirable that the PL layer not become the bottleneck when 770 larger bandwidth pipes become available. To pick a mythical example 771 in today's terms, if a 100Gbps pipe is available and there is 772 sufficient work then the PL layer should be able to take advantage of 773 this and use all of the 100Gbps pipe. Two mechanisms are provided to 774 achieve this. The first one is batching and the second one is a 775 command window. 777 Batching is the ability to send multiple commands (such as Config) in 778 one PDU. The size of the batch will be affected by, amongst other 779 things, the path MTU. The commands may be part of the same 780 transaction or part of unrelated transactions that are independent of 781 each other. 783 Command windowing allows for pipelining of independent transactions 784 which do not affect each other. Each independent transaction could 785 consist of one or more batches. 787 3.3.3.1 Batching 789 There are several batching levels at different protocol hierarchies. 790 o multiple PL PDUs can be aggregated under one TML message 791 o multiple LFB classes and instances can be addressed within one PL 792 PDU 793 o Multiple operations can be addressed to a single LFB class and 794 instance 796 3.3.3.2 Command Pipelining 798 TBD 800 4. TML Requirements 802 The requirements below are expected to be delivered by the TML. This 803 text does not define how such mechanisms are delivered. As an 804 example they could be defined to be delivered via hardware or 805 inter-TML protocol level schemes. 807 Each TML must describe how it contributes to achieving the listed 808 ForCES requirements. If for any reason a TML does not provide a 809 service listed below a justification needs to be provided. 810 1. Reliability 811 As defined by RFC 3654, section 6 #6. 812 2. Security 813 TML provides security services to the ForCES PL. TML layer 814 should support the following security services and describe how 815 they are achieved. 816 * Endpoint authentication of FE and CE. 817 * Message Authentication 818 * Confidentiality service 819 3. Congestion Control 820 The congestion control scheme used needs to be defined. 821 Additionally, the circumstances under which notification is sent 822 to the PL to notify it of congestion must be defined. 823 4. Uni/multi/broadcast addressing/delivery if any 824 If there is any mapping between PL and TML level 825 Uni/Multi/Broadcast addressing it needs to be defined. 826 5. Timeliness 828 Editorial Note: Does the TML allow for obsoleting msgs? If yes, 829 it needs to define how. 830 6. HA decisions 831 It is expected that availability of transport links is the TML's 832 responsibility. However, on config basis, the PL layer may wish 833 to participate in link failover schemes and therefore the TML 834 must support this capability. 835 Please refer to the HA Section Section 8 for details. 836 7. Encapsulations used. 837 Different types of TMLs will encapsulate the PL messages on 838 different types of headers. The TML needs to specify the 839 encapsulation used. 840 8. Prioritization 841 It is expected that the TML will be able to handle up to 8 842 priority levels needed by the PL layer and will provide 843 preferential treatment. 844 TML needs to define how this is achieved. 845 9. Protection against DoS attacks 846 As described in the Requirements RFC 3654, section 6 848 4.1 TML Parameterization 850 It is expected that it should be possible to use a configuration 851 reference point, such as the FEM or the CEM, to configure the TML. 853 Some of the configured parameters may include: 854 o PL ID 855 o Connection Type and associated data. For example if a TML uses 856 IP/TCP/UDP then parameters such as TCP and UDP ports, IP addresses 857 need to be configured. 858 o Number of transport connections 859 o Connection Capability, such as bandwidth, etc. 860 o Allowed/Supported Connection QoS policy (or Congestion Control 861 Policy) 863 5. Message encapsulation 865 All PL layer PDUs start with a common header [Section 5.1] followed 866 by a one or more TLVs [Section 5.2] which may nest other TLVs 867 [Section 5.2.1]. 869 5.1 Common Header 871 0 1 2 3 872 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 873 0 1 2 3 874 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 875 |version| rsvd | Message Type | Length | 876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 877 | Source ID | 878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 879 | Destination ID | 880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 881 | Sequence Number | 882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 883 | Flags | 884 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 886 Figure 6: Common Header 888 The message is 32 bit aligned. 890 Version (4 bit): 891 Version number. Current version is 1. 892 rsvd (4 bit): 893 Unused at this point. A receiver should not interpret this 894 field. Senders SHOULD set it to zero. 895 Command (8 bits): 896 Commands are defined in Section 6. 897 Source ID (32 bit): 898 Dest ID (32 bit): 899 * Each of the source and Dest IDs are 32 bit IDs which 900 recognize the termination points. Ideas discussed so far are 901 desire to recognize if ID belongs to FE or CE by inspection. 902 Suggestions for achieving this involves partitioning of the 903 ID allocation. Another alternative maybe to use flags to 904 indicate direction (this avoids partition). 905 * IDs will allow multi/broad/unicast 906 * Addressing 907 a. As ForCES may run between multiple CEs and FEs and over 908 different protocols such as IPv4 and IPv6, or directly 909 over Ethernet or other switching-fabric interconnects, it 910 is necessary to create an addressing scheme for ForCES 911 entities. Mappings to the underlying TML-level 912 addressing can then be defined as appropriate. 913 b. Fundamentally, unique IDs are assigned to CEs and FEs. A 914 split address space is used to distinguish FEs from CEs. 915 Even though we can assume that in a large NE there are 916 typically two or more orders of magnitude more FEs than 917 CEs, the address space is split uniformly for simplicity. 918 c. Special IDs are reserved for FE broadcast, CE broadcast, 919 and NE broadcast. 920 d. Subgroups of FEs belonging, for instance, to the same 921 VPN, may be assigned a multicast ID. Likewise, subgroups 922 of CEs that act, for instance, in a back-up mode may be 923 assigned a multicast ID. These FEs and CE multicast IDs 924 are chosen in a distinct portion of the ID address space. 925 Such a multicast ID may comprise FEs, CEs, or a mix of 926 both. 927 e. As a result, the address space allows up to 2^30 (over a 928 billion) CEs and the same amount of FEs. 930 0 1 2 3 931 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 932 0 1 2 3 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 |TS | sub-ID | 935 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 937 Figure 7: ForCES ID Format 939 f. The ForCES ID is 32 bits. The 2 most significant bits 940 called Type Switch (TS) are used to split the ID space as 941 follows: 942 A. TS Corresponding ID range Assignment 943 B. -- ---------------------- ---------- 944 C. 0b00 0x00000000 to 0x3FFFFFFF FE IDs (2^30) 945 D. 0b01 0x40000000 to 0x7FFFFFFF CE IDs (2^30) 946 E. 0b10 0x80000000 to 0xBFFFFFFF reserved 947 F. 0b11 0xC0000000 to 0xFFFFFFEF multicast IDs 948 (2^30 - 16) 949 G. 0b11 0xFFFFFFF0 to 0xFFFFFFFC reserved 950 H. 0b11 0xFFFFFFFD all CEs broadcast 951 I. 0b11 0xFFFFFFFE all FEs broadcast 952 J. 0b11 0xFFFFFFFF all FEs and CEs 953 (NE) broadcast 954 g. It is desirable to address multicast and/or broadcast 955 messages to some LFB instances of a given class. For 956 instance, assume FEs FEa and FEb: 957 - FEa has LFBs LFBaX1 and LFBaX2 of class X 958 - similarly, FEb has two LFBs LFBbX1 and LFBbX2 of 959 class X. 960 A broadcast message should be addressable to only LFBs 961 LFBaX1 and LFBbX1 (this can be the case for instance if 962 these two LFBs belong to the same VPN). To achieve this, 963 a VPN ID (3 octets OUI and 4 octets VPN Index) as defined 964 in RFC 2685 should be used within the ForCES message body 965 as a TLV. 967 As an alternative, a particular multicast ID MAY be 968 associated to a given VPN ID through some configuration 969 means. Messages delivered to such a multicast ID MUST 970 only be applied to LFBs belonging to that VPN ID. 972 Sequence (32 bits) 973 Unique to a PDU. [Discussion: There may be impact on the effect 974 of subsequence numbers]. 975 Length (16 bits): 976 length of header + the rest of the message in DWORDS (4 byte 977 increments). 978 Flags(32 bits): 979 Identified so far: 980 - ACK indicator(2 bit) 981 The description for using the two bits is: 982 'NoACK' (00) 983 'SuccessACK'(01) 984 'UnsuccessACK'(10) 985 'ACKAll' (11) 986 - Priority (3 bits) 987 TBD 988 - Throttle flag 989 - Batch (2 bits) 990 - Atomicity (1 or more bits. TBD) 992 Editorial Note: There are several open issues, listed below, in the 993 header which still need to be settled: 995 1. Parallelization of PL Windowing/subsequence 996 Someone to look into ISCSI 997 2. events and replies and relation to peer to peer 998 vs master slave 999 3. We need to discuss whether some of the Flags 1000 such as those for Atomicity, Batching are needed 1001 in the common header or only belong to the PATH 1002 flags. 1004 5.2 Type Length Value 1006 0 1 2 3 1007 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 1008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1009 | TLV Type | variable TLV Length | 1010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1011 | Value (Data of size TLV length) | 1012 ~ ~ 1013 ~ ~ 1014 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1016 TLV Type: 1018 The TLV type field is two octets, and indicates the type of data 1019 encapsulated within the TLV. 1021 TLV Length: 1023 The TLV Length field is two octets, and indicates the length of 1024 this TLV including the TLV Type, TLV Length, and the TLV data. 1026 TLV Value: 1028 The TLV Value field carries the data. For extensibility, the TLV 1029 Value may be a TLV. In fact, this is the case with the 1030 Netlink2-extension TLV. The Value encapsulated within a TLV is 1031 dependent of the attribute being configured and is opaque to 1032 Netlink2 and therefore is not restricted to any particular type 1033 (example could be ascii strings such as XML, or OIDs etc). 1035 TLVs must be 32 bit aligned. 1037 Figure 8: TLV 1039 5.2.1 Nested TLVs 1041 TLV values can be other TLVs. This provides the benefits of protocol 1042 flexibility (being able to add new extensions by introducing new TLVs 1043 when needed). The nesting feature also allows easy mapping between 1044 the XML LFB definitions to binary PL representation. 1046 5.2.2 Scope of the T in TLV 1048 The "Type" value in TLV is of global scope. This means that wherever 1049 in the PDU hierachy a Type has global connotations. This is a design 1050 choice to ease debugging of the protocol. 1052 6. Protocol Construction 1054 6.1 Protocol Grammar 1056 The protocol construction is formally defined using a BNF-like syntax 1057 to describe the structure of the PDU layout. This is matched to a 1058 precise binary format later in the document. 1060 Since the protocol is very flexible and hierachical in nature, it is 1061 easier at times to see the visualization layout. This is provided in 1062 Section 6.1.2 1064 6.1.1 Protocol BNF 1066 The format used is based on RFC 2234. The terminals of this gramar 1067 are flags, IDcount, IDs, KEYID, KEY_DATA and DATARAW, described after 1068 the grammar. 1069 1. A TLV will have the word "TLV" at the end of its name 1070 2. / is used to separate alternatives 1071 3. parenthesised elements are treated as a single item 1072 4. * before an item indicates 0 or more repetitions 1* before an 1073 item indicates 1 or more repetitions 1074 5. [] around an item indicates that it is optional (equal to *1) 1076 The BNF of the PL level PDU is as follows: 1078 PL level PDU := MAINHDR 1*LFBselect-TLV 1079 LFBselec-TLV := LFBCLASSID LFBInstance 1*OPER-TLV 1080 OPER-TLV : = 1*PATH-DATA-TLV 1081 PATH-DATA-TLV := PATH [DATA] 1082 PATH := flags IDcount IDs [SELECTOR] 1083 SELECTOR := KEYINFO-TLV 1084 DATA := DATARAW-TLV / RESULT-TLV / 1*PATH-DATA-TLV 1085 KEYINFO-TLV := KEYID KEY_DATA 1086 DATARAW-TLV := encoded data which may nest DATARAW TLVs 1087 RESULT-TLV := not yet defined. Holding result code and optional DATARAW 1089 o MAINHDR defines a message type, Target FE/CE ID etc. The MAINHDR 1090 also defines the content. As an example the content of a "config" 1091 message would be different from an "association" message. 1092 o LFBCLASSID is a 32 bit unique identifier per LFB class defined at 1093 class Definition time. 1094 o LFBInstance is a 32 bit unique instance identifier of an LFB class 1095 o OPERATION is one of {ADD,DEL,etc.} depending on the message type 1096 [Editorial note: List all known operations here] 1098 o PATH-DATA-TLV identifies the exact element targeted. It may have 1099 zero or more paths associated with it terminated by zero or more 1100 data values associated. 1101 * Note: SELECTOR is retained in this grammar to allow for future 1102 extensibility. 1103 * NOTE! NOTE! There is a selector known as BLKINFO that is left 1104 out of this doc for now that will be revisted later. BLKINFO 1105 is defined as: 1106 * SELECTOR := KEYINFO-TLV / BLOCK-SELECTION-TLV BLKINFO TLV := 1107 [BLK_RANGE_INDEX] / [BLK_LIST_INDEX] / [BLK_CNT_INDEX] A 1108 PathData can only have one selector either a KEYINFO TLV or a 1109 BLKINFO TLV (i.e not both). 1110 o PATH provides the path to the data being referenced. 1111 * flags (16 bits) are used to further refine the operation to be 1112 applied on the Path. More on these later. 1113 * IDcount(16 bit): count of 32 bit IDs 1114 * IDs: zero or more 32bit IDs (whose count is given by IDcount) 1115 defining the main path. Depending on the flags, IDs could be 1116 field IDs only or a mix of field and dynamic IDs. Zero is used 1117 for the special case of using the entirety of the containing 1118 context as the result of the path. 1119 o SELECTOR is an optional construct that further defines the PATH. 1120 Currently, the only defined selector is the KEYINFO-TLV, used for 1121 selecting an array entry by the value of a key field. The 1122 presence of a SELECTOR is correct only when the flags also 1123 indicate its presence. A mismatch is a protocol format error. 1124 o A KEYINFO TLV contains information used in content keying. 1125 * A KeyID is used in a KEYINFO TLV. It indicates which key for 1126 the current array is being used as the content key for array 1127 entry selection. 1128 * KEY_DATA is the data to look for in the array, in the fields 1129 identified by the keyfield. The information is encoded 1130 according to the rules for the contents of a DATARAW, and 1131 represent the field or fields which make up the key identified 1132 by the KEYID. 1133 o DATA may contain a DATARAW or 1 or more further PATH-DATA 1134 selection DATARAW is only allowed on SET requests, or on responses 1135 which return content information (GET Response for example.) 1136 PATH-DATA may be included to extent the path on any request. 1137 * Note: Nested PATH-DATA TLVs are supported as an efficiency 1138 measure to permit common subexpression extraction. 1139 * DATARAW contains "the data" whose path is selected. 1140 o RESULT contains the indication of whether the individual SET 1141 succeeded. If there is an indication for verbose response, then 1142 SETRESULT will also contain the DATARAW showing the data that was 1143 set. RESULT-TLV is included on the assumption that individual 1144 parts of a SET request can succeed or fail separately. Note: This 1145 is one of several ways of handling set results. This is still 1146 being discussed. 1148 In summary this approach has the following characteristic: 1149 o There can be one or more LFB Class + InstanceId combo targeted in 1150 a message (batch) 1151 o There can one or more operations on an addressed LFB 1152 classid+instanceid combo(batch) 1153 o There can be one or more path targets per operation (batch) 1154 o Paths may have zero or more data values associated (flexibility 1155 and operation specific) 1157 It should be noted that the above is optimized for the case of a 1158 single classid+instance targeting. To target multiple instances 1159 within the same class, multiple LFBselect are needed. 1161 6.1.1.1 Discussion on Grammar 1163 Data is packed in such a way that a receiver of such data with 1164 knowledge of the path can correlate what it means by infering in the 1165 LFB definition. This is an optimization that helps reducing the 1166 amount of description for the data in the protocol. 1168 In other words: 1170 It is assumed that the type of the data can be inferred by the 1171 context in which data is used. Hence, data will not include its type 1172 information. The basis for the inference is typically the LFB class 1173 id and the path. 1175 OPEN ISSUE: There is another view of how DATA should be represented 1176 posted a while back by Zsolt/Steve. We need to review it and compare 1177 against the scheme described here. The criteria is: 1178 o efficiency of encoding 1179 o efficiency of parsing and decoding 1180 o the packaging overhead. 1182 6.1.1.1.1 Data Packing Rules 1184 The scheme for packaging data used in this doc adheres to the 1185 following rules: 1186 o The Value of DATARAW TLV will contain the data being transported. 1187 This data will be as was described in the LFB definition. 1188 o By definition in the Forces protocol, all TLVs are 32 bit aligned. 1189 Therefore because DATARAW is a TLV, elements not aligned in 32 bit 1190 values will be padded. 1191 o As an example a 16 bit value will have an extra 16 bit pad; 1192 however two 16 bits values in a structure will be shipped together 1193 with no padding etc. 1195 o Variable sized data will be encapsulated inside another DATARAW 1196 TLV inside the V of the outer TLV. For example of this see 1197 Appendix D example 13. 1198 o When a table is refered in the PATH (ids), then the RAWDATA's V 1199 will contain that tables row content prefixed by its 32 bit 1200 index/subscript OTOH, when SELECTOR flags are 00, the PATH may 1201 contain an index pointing to a row in table; in such a case, the 1202 RAWDATA's V will only contain the content sans the index in order 1203 to avoid ambiguity. 1205 6.1.1.1.2 Path Flags 1207 The following flags are currently defined: 1208 o SELECTOR Bit: F_SELKEY indicates that a KEY Selector is present 1209 following this path information, and should be considered in 1210 evaluating the path. 1211 o FIND-EMPTY Bit: This must not be set if the F_SEL_KEY bit is set. 1212 This must only be used on a create operation. If set, this 1213 indicates that although the path identifies an array, the SET 1214 operation should be applied to the first unused element in the 1215 array. The result of the operation will not have this flag set, 1216 and will have the assigned index in the path. 1218 6.1.1.1.3 Relation of operational flags with global message flags 1220 Should be noted that other applicable flags such as atomicity 1221 indicators as well as verbosity result formaters are in the main 1222 headers flags area. 1224 6.1.1.1.4 Content Path Selection 1226 The KEYINFO TLV describes the KEY as well as associated KEY data. 1227 KEYs, used for content searches, are restricted and described in the 1228 LFB definition. 1230 6.1.1.1.5 Operation TLVs 1232 It is assumed that specific operations are identified by the type 1233 code of the TLV. And that response are also identified by specific 1234 TLV opcodes 1236 6.1.1.1.6 SET and GET Relationship 1238 It is expected that a GET-RESPONSE would satisfy the following 1239 desires: 1240 o it would have exactly the same path definitions as that was sent 1241 in the GET. The only difference being a GET-RESPONSE will contain 1242 DATARAW TLVs. 1244 o it should be possible that one would take the same GET-RESPONSE 1245 and convert it to a SET-REPLACE successfully by merely changing 1246 the T in the operational TLV. 1247 o There are exceptions to this rule: 1248 1. When a KEY selector is used with a path in a GET operation, 1249 that selector is not returned in the GET-RESPONSE; instead the 1250 cooked result is returned. Refer to the examples using KEYS 1251 to see this. 1252 2. When dumping a whole table in a GET, the GET-RESPONSE, merely 1253 editing the T to be SET will endup overwritting the table. 1255 6.1.2 Protocol Visualization 1257 The figure below shows a general layout of the PL PDU. A main header 1258 is followed by one or more LFB selections each of which may contain 1259 one or more operation. 1261 main hdr (Config in this case) 1262 | 1263 | 1264 +--- T = LFBselect 1265 | | 1266 | +-- LFBCLASSID 1267 | | 1268 | | 1269 | +-- LFBInstance 1270 | | 1271 | +-- T = SET-CREATE 1272 | | | 1273 | | +-- // one or more path targets 1274 | | // with their data here to be added 1275 | | 1276 | +-- T = DEL 1277 | . | 1278 | . +-- // one or more path targets to be deleted 1279 | 1280 | 1281 +--- T = LFBselect 1282 | | 1283 | +-- LFBCLASSID 1284 | | 1285 | | 1286 | +-- LFBInstance 1287 | | 1288 | + -- T= SET-REPLACE 1289 | | 1290 | | 1291 | + -- T= DEL 1292 | | 1293 | + -- T= SET-REPLACE 1294 | 1295 | 1296 +--- T = LFBselect 1297 | 1298 +-- LFBCLASSID 1299 | 1300 +-- LFBInstance 1301 . 1302 . 1303 . 1305 Figure 10: PL PDU layout 1307 The figure below shows an example general layout of the operation 1308 within a targetted LFB selection. The idea is to show the different 1309 nesting levels a path could take to get to the target path. 1311 T = SET-CREATE 1312 | | 1313 | +- T = Path-data 1314 | | 1315 | + -- flags 1316 | + -- IDCount 1317 | + -- IDs 1318 | | 1319 | +- T = Path-data 1320 | | 1321 | + -- flags 1322 | + -- IDCount 1323 | + -- IDs 1324 | | 1325 | +- T = Path-data 1326 | | 1327 | + -- flags 1328 | + -- IDCount 1329 | + -- IDs 1330 | + -- T = KEYINFO 1331 | | + -- KEY_ID 1332 | | + -- KEY_DATA 1333 | | 1334 | + -- T = DATARAW 1335 | + -- data 1336 | 1337 | 1338 T = SET-REPLACE 1339 | | 1340 | +- T = Path-data 1341 | | | 1342 | | + -- flags 1343 | | + -- IDCount 1344 | | + -- IDs 1345 | | | 1346 | | + -- T = DATARAW 1347 | | + -- data 1348 | +- T = Path-data 1349 | | 1350 | + -- flags 1351 | + -- IDCount 1352 | + -- IDs 1353 | | 1354 | + -- T = DATARAW 1355 | + -- data 1356 T = DEL 1357 | 1358 +- T = Path-data 1359 | 1360 + -- flags 1361 + -- IDCount 1362 + -- IDs 1363 | 1364 +- T = Path-data 1365 | 1366 + -- flags 1367 + -- IDCount 1368 + -- IDs 1369 | 1370 +- T = Path-data 1371 | 1372 + -- flags 1373 + -- IDCount 1374 + -- IDs 1375 + -- T = KEYINFO 1376 | + -- KEY_ID 1377 | + -- KEY_DATA 1378 +- T = Path-data 1379 | 1380 + -- flags 1381 + -- IDCount 1382 + -- IDs 1384 Figure 11: Sample operation layout 1386 6.2 Core ForCES LFBs 1388 There are three LFBs that are used to control the operation of the 1389 ForCES protocol and to interact with FEs and CEs: 1390 FE protocol LFB 1391 FE LFB 1392 CE LFB 1394 Although these LFBs have the same form and interface as other LFBs, 1395 they are special in many respects: they have fixed well-known LFB 1396 Class and Instance IDs. They are statically defined (no dynamic 1397 instantiation allowed) and their status cannot be changed by the 1398 protocol: any operation to change the state of such LFBs (for 1399 instance, in order to disable the LFB) must result in an error. 1400 Moreover, these LFBs must exist before the first ForCES message can 1401 be sent or received. All attributes in these LFBs must have 1402 pre-defined default values. Finally, these LFBs do not have input or 1403 output ports and do not integrate into the intra-FE LFB topology. 1405 Editorial Note: The CE LFB is under discussion still and may end up 1406 being removed. 1408 6.2.1 FE Protocol LFB 1410 The FE Protocol LFB is a logical entity in each FE that is used to 1411 control the ForCES protocol. The FE Protocol LFB Class ID is 1412 assigned the value 0x1. The FE LFB Instance ID is assigned the value 1413 0x1. There must always be one and only one instance of the FE 1414 Protocol LFB in an FE. The values of the attributes in the FE 1415 Protocol LFB have pre-defined default values that are specified here. 1416 Unless explicit changes are made to these values using Config 1417 messages from the CE, these default values MUST be used for the 1418 operation of the protocol. 1420 The formal definition of the FE Protocol LFB can be found in 1421 Appendix C 1423 The FE Protocol LFB consists of the following elements: 1424 o FE Protocol events that can be subscribed/unsubscribed: 1425 * FE heartbeat 1426 * FE TML events (TBD) 1427 o FE Protocol capabilities (read-only): 1428 * Supported ForCES protocol version(s) by the FE 1429 * Supported ForCES FE model(s) by the FE 1430 * Some TML capability description(s) 1431 o FE Protocol attributes (can be read and set): 1432 * Current version of the ForCES protocol 1433 * Current version of the FE model 1434 * FE unicast ID 1435 * FE multicast ID(s) (list) 1436 * Association Expiry Timer 1437 * Heartbeat Interval 1438 * Primary CE 1439 * FE failover and restart policy 1440 * CE failover and restart policy 1441 Note: Is there a difference between the CE and FE failover 1442 policies? 1443 TBD: Define default values for each attribute where 1444 applicable. 1446 6.2.2 FE Object LFB 1448 The FE Object LFB is a logical entity in each FE and contains 1449 attributes relative to the FE itself, and not to the operation of the 1450 ForCES protocol. The FE LFB Class ID is assigned the value 0x2. The 1451 FE LFB Instance ID is assigned the value 0x1. There must always be 1452 one and only one instance of the FE LFB in an FE. 1454 The formal definition of the FE Object LFB can be found in [FE-MODEL] 1456 The FE LFB consists of the following elements: 1457 FE Events: 1458 * FEAllEvents: subscribing to this corresponds to subscribing to 1459 all events below 1460 * FEStatusChange: events that signal FE Status: 1461 + Up 1462 + Down 1463 + Active 1464 + Inactive 1465 + Failover 1466 * FE DoS alert 1467 * FE capability change 1468 FE attributes: 1469 * FEStatus: to set the FE mode as: 1470 + Active 1471 + Inactive 1472 + Shutdown 1473 Note: This replaces the State Maintenance messages 1474 * FELFBInstancelist 1475 * FENeighborList 1476 * MIID table: a list of virtual LFB Instance IDs that map to a 1477 list of Instance IDs of LFBs in that FE 1479 * FE Behavior Exp. Timer 1480 * HA Mode 1481 * FE DoS protection policy 1482 * FEPrivateData: Proprietary info such as name, vendor, model. 1483 Note: The attributes below were previously under Query 1484 message. 1485 * Inter-FE topology Intra-FE topology 1487 6.2.3 CE LFB 1489 The CE LFB is a logical entity in each CE and contains attributes 1490 relative to the CE itself, and not to the operation of the ForCES 1491 protocol. 1493 Editorial Note: NOTE: The CE LFB is under discussion still and may 1494 end up being removed. 1496 The CE LFB consists of the following elements: 1497 CE Events: 1498 * CEAllEvents: subscribing to this corresponds to subscribing to 1499 all events listed below. 1500 Note: Do we want to allow an FE to explicitly subscribe to CE 1501 events? 1502 * CEStatusChange: events that signal CE 1503 Up/Down/Active/Inactive/Failover. 1504 Note: Such events do not necessarily need to be subscribed to, 1505 they can fire even without subscription and be sent to 1506 the FE 1507 Note: TBD: what else do we need in the CE LFB? 1509 6.3 Semantics of message Direction 1511 Recall: The PL protocol provides a master(CE)-Slave(FE) relationship. 1512 The LFBs reside at the FE and are controlled by CE. 1514 When messages go from the CE, the LFB Selector (Class and instance) 1515 refers to the destination LFB selection which resides in the FE. 1517 When messages go from the FE->CE, the LFB Selector (Class and 1518 instance) refers to the source LFB selection which resides in the FE. 1520 6.4 Association Messages 1522 The ForCES Association messages are used to establish and teardown 1523 associations between FEs and CEs. 1525 6.4.1 Association Setup Message 1527 This message is sent by the FE to the CE to setup a ForCES 1528 association between them. This message could also be used by CEs to 1529 join a ForCES NE, however CE-to-CE communication is not covered by 1530 this protocol. 1532 Message transfer direction: 1533 FE to CE 1534 Message Header: 1535 The Message Type in the header is set MessageType= 'Association 1536 Setup'. The ACK flag in the header is ignored, because the setup 1537 message will always expect to get a response from the message 1538 receiver (CE) whether the setup is successful or not. The Src ID 1539 (FE ID) may be set to O in the header which means that the FE 1540 would like the CE to assign a FE ID for the FE in the setup 1541 response message. 1542 Message body: 1543 The LFB selection points to the FE Object and more than one FE 1544 Object attribute may be announced in this message. The layout 1545 looks like: 1547 main hdr (eg type = Association setup) 1548 | 1549 | 1550 +--- T = LFBselect 1551 | | 1552 | +-- LFBCLASSID = FE object 1553 | | 1554 | | 1555 | +-- LFBInstance = 0x1 1556 | | 1557 | +--- T = Operation = SHOW 1558 | | 1559 | +-- Path-data to one or more attibutes 1560 | including FE NAME 1561 +--- T = LFBselect 1562 | 1563 +-- LFBCLASSID = FE Protocol object 1564 | 1565 | 1566 +-- LFBInstance = 0x1 1567 | 1568 +--- T = Operation = SHOW 1569 | 1570 +-- Path-data to one or more attibutes 1571 including suggested HB parameters 1573 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 1575 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1576 | Type = LFB select | Length | 1577 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1578 | LFB Class ID = FE Object | 1579 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1580 | LFB Instance ID | 1581 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1582 | Type = operation Show | Length | 1583 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1584 | | 1585 ~ Attributes path and data ~ 1586 ~ ~ 1587 ~ ~ 1588 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1589 | Type = LFB select | Length | 1590 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1591 | LFB Class ID = FE Protocol Object | 1592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1593 | LFB Instance ID | 1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1595 | Type = operation Show | Length | 1596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1597 | | 1598 ~ ~ 1599 ~ Attributes path and data ~ 1600 ~ ~ 1601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1603 Figure 12 1605 Type (16 bits): 1606 LFB Select 1607 Length (16 bits): 1608 Length of the TLV including the T and L fields, in bytes. 1609 FE Object and Protocol LFBs: 1610 These contains the FE parameters e.g. HBI will be exchanged with 1611 the CE using the FE Protocol LFB. 1612 Editorial Note: In certain situations (such as use of multicast 1613 IDs), it might not be possible to make use of the 1614 procedure described above for the FE to 1615 dynamically obtain an ID from the CE. Such 1616 situations need to be identified. 1618 this message will still require some small 1619 discussion; for now goal is to convert to 1620 something using the two core FE LFBs. 1622 6.4.2 Association Setup Response Message 1624 This message is sent by the CE to the FE in response to the Setup 1625 message. It indicates to the FE whether the setup is successful or 1626 not, i.e. whether an association is established. 1628 Message transfer direction: 1629 CE to FE 1630 Message Header: 1631 The Message Type in the header is set MessageType= 'Setup 1632 Response'. The ACK flag in the header is always ignored, because 1633 the setup response message will never expect to get any more 1634 response from the message receiver (FE). The Dst ID in the 1635 header will be set to some FE ID value assigned by the CE if the 1636 FE had requested that in the setup message (by SrcID = 0). 1637 Message body: 1638 The setup response message body consists of LFBSelect & Result 1639 TLV, the format of which is as follows: 1641 main hdr (eg type = Association setup response) 1642 | 1643 | 1644 | 1645 +--- T = LFBselect 1646 | | 1647 | +-- LFBCLASSID = FE object 1648 | | 1649 | | 1650 | +-- LFBInstance = 0x1 1651 | | 1652 | +--- T = Operation = SHOW 1653 | | 1654 | +-- Path-data to one or more attibutes 1655 | including FE NAME 1656 | May contain RESULT TLVs 1657 +--- T = LFBselect 1658 | 1659 +-- LFBCLASSID = FE Protocol object 1660 | 1661 | 1662 +-- LFBInstance = 0x1 1663 | 1664 +--- T = Operation = SHOW 1665 | 1666 +-- Path-data to one or more attibutes 1667 eg HB parameters 1668 May contain RESULT TLVs 1670 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 1672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1673 | Type = LFB select | Length | 1674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1675 | LFB Class ID = FE Object | 1676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1677 | LFB Instance ID | 1678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1679 | Type = operation Show | Length | 1680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1681 | | 1682 ~ Attributes path and data ~ 1683 ~ ~ 1684 ~ ~ 1685 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1686 | Type = LFB select | Length | 1687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1688 | LFB Class ID = FE Protocol Object | 1689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1690 | LFB Instance ID | 1691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1692 | Type = operation Show | Length | 1693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1694 | | 1695 ~ ~ 1696 ~ Attributes path and data ~ 1697 ~ ~ 1698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1700 Figure 13 1702 Type (16 bits): 1703 LFB Select 1704 Length (16 bits): 1705 Length of the TLV including the T and L fields, in bytes. 1706 FE Object LFB: 1707 The FE parameters e.g. HBI may be exchanged using this LFB. 1709 Result (16 bits): 1710 This indicates whether the setup msg was successful or whether 1711 the FE request was rejected by the CE. 1713 6.4.3 Association Teardown Message 1715 This message can be sent by the FE or CE to any ForCES element to end 1716 its ForCES association with that element. 1718 Message transfer direction: 1719 CE to FE, or FE to CE (or CE to CE) 1720 Message Header: 1721 The Message Type in the header is set MessageType= "Asso. 1722 Teardown". The ACK flag in the header is always ignored, because 1723 the teardown message will never expect to get any response from 1724 the message receiver. 1725 Message body: 1726 The association teardown message body consists of LFBSelect & 1727 FEReason TLV, the format of which is as follows: 1728 Editorial Note: Details of how Reason will be carried in the 1729 Teardown message are still unclear. There is no 1730 such attribute at the FE Object at the moment. 1731 There is also no operation by the name of 1732 FEReason. 1734 main hdr (eg type = Association tear) 1735 | 1736 | 1737 | 1738 | 1739 +--- T = LFBselect 1740 | 1741 +-- LFBCLASSID = FE object 1742 | 1743 | 1744 +-- LFBInstance = 0x1 1745 | 1746 +--- T = Operation = FEReason 1747 | 1748 +-- Path-data to string containing reason 1750 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 1752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1753 | Type = LFB select | Length | 1754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1755 | LFB Class ID = FE Object | 1756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1757 | LFB Instance ID | 1758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1759 | Type = T.reason | Length | 1760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1761 | Reason | 1762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1764 Figure 14 1766 Type (16 bits): 1767 LFB Select 1768 Length (16 bits): 1769 Length of the TLV including the T and L fields, in bytes. 1770 T.reason (32 bits): 1771 This indicates the reason why the association is being 1772 terminated. 1774 6.5 Configuration Messages 1776 The ForCES Configuration messages are used by the CEs to configure 1777 the FEs in a ForCES NE and report the results back to the CE. 1779 6.5.1 Config Message 1781 This message is sent by the CE to the FE to configure FE or LFB 1782 attributes. This message is also used by the CE to 1783 subscribe/unsubscribe to FE and LFB events. 1785 Message transfer direction: 1786 CE to FE 1787 Message Header: 1788 The Message Type in the header is set MessageType= 'Config'. The 1789 ACK flag in the header is can be used by the CE to turn off any 1790 response from the FE. The default behavior is to turn on the ACK 1791 to get the config response from the FE. 1792 Message body: 1793 The Config message body consists of one or more TLVs, the format 1794 of a single (LFB) TLV is as follows: 1796 main hdr (eg type = config) 1797 | 1798 | 1799 +--- T = LFBselect 1800 | | 1801 | +-- LFBCLASSID = target LFB class 1802 | | 1803 | | 1804 | +-- LFBInstance = target LFB instance 1805 | | 1806 | | 1807 | +-- T = operation { GET, DEL, etc} 1808 | | | 1809 | | +-- // one or more path targets 1810 | | // discussed later 1811 | | 1812 | +-- T = operation { GET, DEL, etc} 1813 | | | 1814 | | +-- // one or more path targets 1815 | | // discussed later 1816 | | 1817 | +-- T = operation { GET, DEL, etc} 1818 | | | 1819 | | +-- // one or more path targets 1820 | | // discussed later 1821 | | 1823 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 1824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1825 | Type = LFB select | Length | 1826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1827 | LFB Class ID | 1828 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1829 | LFB Instance ID | 1830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1831 | Operation (GET) | Length | 1832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1833 | | 1834 ~ Config path ~ 1835 | | 1836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1837 | Operations (DEL) | Length | 1838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1839 | | 1840 ~ Config path ~ 1841 | | 1842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1844 Figure 15 1846 Type (16 bits): 1847 LFB Select. 1848 Length (16 bits): 1849 Length of the TLV including the T and L fields, in bytes. 1850 LFB Class ID (16 bits): 1851 This field uniquely recognizes the LFB class/type. 1852 LFB Instance ID (16 bits): 1853 This field uniquely identifies the LFB instance. 1854 Type (16 bits): 1855 The operations include, ADD, DEL, UPDATE/REPLACE, DEL ALL, EVENT 1856 SUBSCRIBE, EVENT UNSUBSCRIBE, CANCEL(under discussion). 1857 Length (16 bits): 1858 Length of the TLV including the T and L fields, in bytes. 1859 Config path + Data (variable length): 1860 This will carry LFB specific data (, presentation 1861 preliminary found in this doc but still TBD. ). The config data 1862 might itself be of the form of a TLV. Should be noted only a 1863 CREATE, REPLACE will have data while the rest will only carry 1864 path information of what to DELete or GET. 1865 *Note: FE Activate/Deactivate, Shutdown FE commands for State 1866 Maintenance will be sent using Config messages. 1867 *Note: For Event subscription, the events will be defines by the 1868 individual LFBs. 1870 6.5.2 Config Response Message 1872 This message is sent by the FE to the CE in response to the Config 1873 message. It indicates whether the Config was successful or not on 1874 the FE and also gives a detailed response regarding the configuration 1875 result of each attribute. 1877 Message transfer direction: 1878 FE to CE 1879 Message Header: 1880 The Message Type in the header is set MessageType= 'Config 1881 Response'. The ACK flag in the header is always ignored, because 1882 the config response message will never expect to get any more 1883 response from the message receiver (CE). 1884 Message body: 1885 The Config response message body consists of one or more TLVs, 1886 the format of a single TLV is as follows: 1888 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 1890 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1891 | Type = LFB select | Length | 1892 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1893 | LFB Class ID | 1894 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1895 | LFB Instance ID | 1896 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1897 | Operations (GET) | Length | 1898 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1899 | Operation Result | reserved | 1900 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1901 | | 1902 ~ Config Result ~ 1903 | | 1904 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1905 | Type = Operations (DEL) | Length | 1906 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1907 | Operation Result | reserved | 1908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1909 | | 1910 ~ Config Result ~ 1911 | | 1912 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1914 Figure 16 1916 Editorial Note: The operation result etc is still under 1917 discussion and will depend on verbosity levels in the main 1918 message headers 1920 Type (16 bits): 1921 LFB Select. 1922 Length (16 bits): 1923 Length of the TLV including the T and L fields, in bytes. 1924 LFB Class ID (16 bits): 1925 This field uniquely recognizes the LFB class/type. 1926 LFB Instance ID (16 bits): 1927 This field uniquely identifies the LFB instance. 1928 Type (16 bits): 1929 The operations are same as those defined for Config messages. 1930 Length (16 bits): 1931 Length of the TLV including the T and L fields, in bytes. 1932 Operation Result (16 bits): 1933 This indicates the overall result of the config operation, 1934 whether it was successful or it failed. 1935 Config Result (variable length): 1936 This will carry LFB specific results (single or Array LFB 1937 specific result entries). The config result might itself be of 1938 the form of a TLV. 1940 6.6 Query and Query Response Messages 1942 The ForCES query and query response messages are used by ForCES 1943 elements (CE or FE) to query LFBs in other ForCES element(s) Current 1944 version of ForCES protocol limits the use of the messages only for CE 1945 to query information of FE. 1947 6.6.1 Query Message 1949 As usual, a query message is composed of a common header and a 1950 message body that consists of one or more TLV data format. Detailed 1951 description of the message is as below. 1953 Message transfer direction: 1954 Current version limits the query message transfer direction only 1955 from CE to FE. 1956 Message Header: 1957 The Message Type in the header is set to MessageType= 'Query'. 1958 The ACK flag in the header SHOULD be set 'ACKAll', meaning a full 1959 response for a query message is always expected. If the ACK flag 1960 is set other values, the meaning of the flag will then be 1961 ignored, and a full response will still be returned by message 1962 receiver. 1963 Message body: 1964 The query message body consists of (at least) one or more than 1965 one TLVs that describe entries to be queried. The TLV is called 1966 LFBselect TLV and the data format is as below: 1968 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 1969 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1970 | Type = LFBselect | Length | 1971 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1972 | LFB Class ID | 1973 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1974 | LFB Instance ID | 1975 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1976 | Operation TLV | 1977 . . 1978 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1979 ~ ... ~ 1980 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1981 | Operation TLV | 1982 . . 1983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1985 Figure 17 1987 Editorial Note: 1988 1. Under discussion is whether there is a need 1989 for explicit multiple LFB insatance 1990 addressing here. One way to realize it is 1991 to define a specific Instance select TLV to 1992 substitute above 'LFB Instance ID' field. 1993 The TLV may have following format: 1995 INSselectTLV := Type Length Value 1996 Type := INSselect 1997 Value := InstanceID (RangeMark | Instance ID)+ 1999 2. An applicable RangeMark is '0xffffffff', the 2000 value of which is the same as Instance 2001 broadcast ID. Because there will be no 2002 broadcast address applied in this place, 2003 there will be no worry of ambiguity here. 2005 Operation TLV: 2006 The Operation TLV for the 'Query' message is formatted as: 2008 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2009 | Type = GET | Length | 2010 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2011 | PATH-DATA for GET | 2012 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2013 Figure 19 2015 PATH-DATA for GET: 2016 This is generically a PATH-DATA format that has been defined in 2017 "Protocol Grammar" section in the PATH-DATA BNF definition, with 2018 the limitation specifically for GET operation that the PATH-DATA 2019 here will not allow DATARAW-TLV and RESULT-TLV present in the 2020 data format, so as to meet the genius of a GET operation. 2022 To better understand the above PDU format, we can show a tree 2023 structure for the format as below: 2025 main hdr (type = Query) 2026 | 2027 | 2028 +--- T = LFBselect 2029 | | 2030 | +-- LFBCLASSID = target LFB class 2031 | | 2032 | | 2033 | +-- LFBInstance = target LFB instance 2034 | | 2035 | | 2036 | +-- T = operation { GET } 2037 | | | 2038 | | +-- // one or more path targets 2039 | | // under discussion 2040 | +-- T = operation { GET } 2041 | | | 2042 | | +-- // one or more path targets 2043 | | 2045 Figure 20 2047 6.6.2 Query Response Message 2049 When receiving a query message, the receiver should process the 2050 message and come up with a query result. The receiver sends the 2051 query result back to the message sender by use of the Query Response 2052 Message. The query result can be the information being queried if 2053 the query operation is successful, or can also be error codes if the 2054 query operation fails, indicating the reasons for the failure. 2056 A query response message is also composed of a common header and a 2057 message body consists of one or more TLVs describing the query 2058 result. Detailed description of the message is as below. 2060 Message transfer direction: 2061 Current version limits the query response message transfer 2062 direction only from FE to CE. 2063 Message Header: 2064 The Message Type in the header is set to MessageType= 2065 'QueryResponse'. The ACK flag in the header SHOULD be set 2066 'NoACK', meaning no further response for a query response message 2067 is expected. If the ACK flag is set other values, the meaning of 2068 the flag will then be ignored. The Sequence Number in the header 2069 SHOULD keep the same as that of the query message to be 2070 responded, so that the query message sender can keep track of the 2071 responses. 2072 Message body: 2073 The message body for a query response message consists of (at 2074 least) one or more than one TLVs that describe query results for 2075 individual queried entries. The TLV is also called LFBselect 2076 TLV, and has exactly the same data format as query message, 2077 except the Operation TLV content is different. The order of the 2078 TLV here matches the TLVs in the corresponding Query message, and 2079 the TLV numbers should also keep the same. The Operation TLV 2080 here is a 'GET-RESPONSE' TLV and the data is a 'PATH-DATA' 2081 format for Query Response Data, as below: 2083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2084 | Type = GET-RESPOSE | Length | 2085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2086 | PATH-DATA for GET-RESPONSE | 2087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2089 Figure 21 2091 PATH-DATA for GET-RESPONSE: 2092 This is generically a PATH-DATA format that has been defined in 2093 "Protocol Grammar" section in the PATH-DATA BNF definition. The 2094 response data will be included in the DATARAW-TLV and/or 2095 RESULT-TLV inside the PATH-DATA format. 2097 6.7 Event Notification and Response Messages 2099 The Event Notification Message is used for one ForCES element to 2100 asynchronously notify one or more other ForCES elements in the same 2101 ForCES NE on just happened events in it. The Event Notification 2102 Response Message is used for the receiver of the Event Notification 2103 Message to acknowledge the reception of the event notification. 2105 Events in current ForCES protocol can be categorized into following 2106 types: 2108 o Events happened in CE 2109 o Events happened in FE 2111 Events can also be categorized into two classes according to whether 2112 they need subscription or not. An event in one ForCES element that 2113 needs to be subscribed will send notifications to other ForCES 2114 elements only when the other elements have subscribed to the element 2115 for the event notification. How to subscribe/unsubscribe for an 2116 event is described in the Configure Message section. An event that 2117 does not need to be subscribed will always send notifications to 2118 other ForCES elements when the event happens. Events will be defined 2119 in the ForCES FE model XML definitions for LFBs as attributes; i.e 2120 they will have a path to them that can be used by the config message 2121 to subscribe to. 2123 Editorial Note: There is an argument that it is preferable to have 2124 all events subscribable. 2126 6.7.1 Event Notification Message 2128 As usual, an Event Notification Message is composed of a common 2129 header and a message body that consists of one or more TLV data 2130 format. Detailed description of the message is as below. 2131 Message Transfer Direction: 2132 FE to CE, or CE to FE 2133 Message Header: 2134 The Message Type in the message header is set to 2135 MessageType = 'EventNotification'. The ACK flag in the header can 2136 be set as: ACK flag ='NoACK'|'SuccessAck'|'UnsuccessACK'|'ACKAll'. 2137 Note that the 'Success' here only means the receiver of the 2138 message has successfully received the message. 2139 Message Body: 2140 The message body for an event notification message consists of (at 2141 least) one or more than one TLVs that describe the notified 2142 events. The TLV is defined as follows: 2144 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 2145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2146 | Type = LFBselect | Length | 2147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2148 | LFB Class ID | 2149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2150 | LFB Instance ID | 2151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2152 | Operation TLV | 2153 . . 2154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2155 ~ ... ~ 2156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2157 | Operation TLV | 2158 . . 2159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2161 Figure 22 2163 Operation TLV: 2164 This is a TLV that describes the event to be notified, as follows: 2166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2167 | OPER = REPORT | Length | 2168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2169 | PATH-DATA for REPORT | 2170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2172 Figure 23 2174 PATH-DATA for REPORT: 2175 This is generically a PATH-DATA format that has been defined in 2176 "Protocol Grammar" section in the PATH-DATA BNF definition. The 2177 report data will be included in the DATARAW-TLV inside the 2178 PATH-DATA format. 2180 To better understand the above PDU format, we can show a tree 2181 structure for the format as below: 2183 main hdr (type = Event Notification) 2184 | 2185 | 2186 +--- T = LFBselect 2187 | | 2188 | +-- LFBCLASSID = target LFB class 2189 | | 2190 | | 2191 | +-- LFBInstance = target LFB instance 2192 | | 2193 | | 2194 | +-- T = operation { REPORT } 2195 | | | 2196 | | +-- // one or more path targets 2197 | | // under discussion 2198 | +-- T = operation { REPORT } 2199 | | | 2200 | | +-- // one or more path targets 2201 | | 2203 Figure 24 2205 6.7.2 Event Notification Response Message 2207 After sending out an Event Notification Message, the sender may be 2208 interested in ensuring that the message has been received by 2209 receivers, especially when the sender thinks the event notification 2210 is vital for system management. An Event Notification Response 2211 Message is used for this purpose. The ACK flag in the Event 2212 Notification Message header are used to signal if such acknowledge is 2213 requested or not by the sender. 2215 Detailed description of the message is as below: 2216 Message Transfer Direction: 2217 >From FE to CE or from CE to FE, just inverse to the direction of 2218 the Event Notification Message that it responses. 2219 Message Header: 2220 The Message Type in the header is set MessageType= 2221 'EventNotificationResponse'. The ACK flag in the header SHOULD be 2222 set 'NoACK', meaning no further response for the message is 2223 expected. If the ACK flag is set other values, the meaning of the 2224 flag will then be ignored. The Sequence Number in the header 2225 SHOULD keep the same as that of the message to be responded, so 2226 that the event notificatin message sender can keep track of the 2227 responses. 2229 Message Body: 2230 The message body for an event notification response message 2231 consists of (at least) one or more than one TLVs that describe the 2232 notified events. The TLV is also called LFBselect TLV, and has 2233 exactly the same data format as Event Notification Message, except 2234 the Operation TLV inside is different. The order of the TLV here 2235 matches the TLVs in the corresponding Event Message, and the TLV 2236 numbers should keep the same. The Operation TLV here is a 2237 'REPORT-RESPONSE' TLV and the data is a 'PATH-DATA' format for 2238 event response data, as below: 2240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2241 | Type = REPORT-RESPONSE | Length | 2242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2243 | PATH-DATA for REPORT-RESPONSE | 2244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2246 Figure 25 2248 PATH-DATA for REPORT-RESPONSE: 2249 This is generically a PATH-DATA format that has been defined in 2250 "Protocol Grammar" section in the PATH-DATA BNF definition. The 2251 response data will be included in the RESULT-TLV inside the 2252 PATH-DATA format. 2254 Editorial Note: There is a debate on whether the Event 2255 Notification Response Message is necessary or 2256 not. The pro for it is some event notification 2257 senders may be interested in knowing if receivers 2258 have had success/unsuccess receptions of the 2259 events or not. An alternative to generate such 2260 response is for the protocol to define a 2261 universal ACK message so that it can act as 2262 responses for any types of messages as well as 2263 the event notification messages, when the message 2264 senders are interested in knowing whether the 2265 messages have been successfully received or not 2266 (different from the responses for the message 2267 processing results). 2269 6.8 Packet Redirect Message 2271 Packet redirect message is used to transfer data packets between CE 2272 and FE. Usually these data packets are IP packets, though they may 2273 sometimes associated with some metadata generated by other LFBs in 2274 the model, or they may occasionally be other protocol packets, which 2275 usually happen when CE and FE are jointly implementing some 2276 high-touch operations. Packets redirected from FE to CE are the data 2277 packets that come from forwarding plane, and usually are the data 2278 packets that need high-touch operations in CE,or packets for which 2279 the IP destination address is the NE. Packets redirected from CE to 2280 FE are the data packets that come from the CE and are decided by CE 2281 to put into forwarding plane in FE. 2283 Supplying such a redirect path between CE and FE actually leads to a 2284 possibility of this path being DoS attacked. Attackers may 2285 maliciously try to send huge spurious packets that will be redirected 2286 by FE to CE, making the redirect path been congested. ForCES 2287 protocol and the TML layer will jointly supply approaches to prevent 2288 such DoS attack. To define a specific 'Packet Redirect Message' 2289 makes TML and CE able to distinguish the redirect messages from other 2290 ForCES protocol messages. 2292 By properly configuring related LFBs in FE, a packet can also be 2293 mirrored to CE instead of purely redirected to CE, i.e., the packet 2294 is duplicated and one is redirected to CE and the other continues its 2295 way in the LFB topology. 2297 Editorial Note: There are also discussions on how LFBs in FE model 2298 that are related to packet redirect operations 2299 should be defined. Although it is out of the scope 2300 of forces protocol, how to define the LFBs affect 2301 the Packet Redirect Message described here. Because 2302 currently it is still in progress in FE model on how 2303 to define such LFBs, we try to post some thoughts on 2304 this here for discussion. They will be removed 2305 later along with the progress of the FE model work. 2307 Thought 1: To define LFBs called 'RedirectSink' and 2308 'RedirectTap' for packet redirect. 2309 An LFB in FE called 'RedirectSink' is responsible to 2310 collect data packets that need to be redirected to 2311 CE. From the perspective of the FE LFB topology, 2312 the 'RedirectSink' LFB is an LFB with only one input 2313 port and without any output port, and the input port 2314 can then be connected to any other LFB in FE model 2315 by means of a datapath in the forwarding plane. 2316 From the perspective of the ForCES protocol layer, 2317 the 'RedirectSink' LFB will generate the Packet 2318 Redirect Messages when it receives data packets from 2319 forwarding plane. 2321 An LFB in FE called 'RedirectTap' is responsible to 2322 receive data packets that are redirected from CE. 2323 From the perspective of the FE LFB topology, the 2324 'RedirectTap' LFB is an LFB with only one output 2325 port and without any input port, and the output port 2326 can then be connected to any other LFB in FE model 2327 by means of a datapath in the forwarding plane. 2328 From the perspective of ForCES protocol layer, the 2329 'RedirectTap' LFB can receive the Packet Redirect 2330 Messages from CE, and un-encapsulate the data 2331 packets from the message and put them to datapaths 2332 in the forwarding plane. Actually the 'RecirectTap' 2333 LFB acts more like a transcoder that transfers the 2334 ForCES protocol messages to normal data packets in 2335 IP forwarding plane. As a result, if we need to 2336 have redirected packets connected to some LFB (say a 2337 Scheduler) in FE model, we only need to connect the 2338 'RedirectTap LFB to the Scheduler LFB directly via a 2339 datapath as follows: 2341 +-----------------+ +-----------+ 2342 | RedirectTap LFB |------>| | 2343 +-----------------+ | | 2344 | Scheduler | 2345 From other LFB ---->| LFB | 2346 | | 2347 +-----------+ 2349 Figure 26 2351 By use of several 'RedirectSink' LFBs and several 2352 'RedirectTap' LFBs that connect to several different 2353 datapaths in FE forwarding plane, multiple packet 2354 redirect paths between CE and FE can be constructed. 2356 Thought 2: There might be another way a packet could be 2357 redirected: directly by a forwarding path, e.g., by 2358 FPGA/ASIC/NP microcode. In such a case we do not 2359 need to put in a lot of smartness. Probably a link 2360 layer or even network level header is enough. The 2361 receiver demuxes it only based on some protocol type 2362 in the link layer or network transport layer. The 2363 pros for this appraoch is it may provide a fast and 2364 cost-effective path for packet redirect. The cons 2365 for this is it may more or less confuses the Fp 2366 reference point definition in ForCES framework. 2368 We describe the Packet Redirect Message data format in details as 2369 follows: 2370 Message Direction: 2371 CE to FE or FE to CE 2372 Message Header: 2373 The Message Type in the header is set to MessageType= 2374 'PacketRedirect'. The ACK flags in the header SHOULD be set 2375 'NoACK', meaning no response is expected by this message. If the 2376 ACK flag is set other values, the meanings will be ignored. 2377 Message Body: 2378 Consists of one or more TLVs, with every TLV having the following 2379 data format: 2381 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 2382 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2383 | Type = LFBselect | Length | 2384 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2385 | LFB Class ID | 2386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2387 | LFB Instance ID | 2388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2389 | Operation TLV | 2390 . . 2391 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2392 ~ ... ~ 2393 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2394 | Operation TLV | 2395 . . 2396 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2398 Figure 27 2400 LFB class ID: 2401 There are only two possible LFB classes here, the 'RedirectSink' 2402 LFB or the 'RedirectTap' LFB. If the message is from FE to CE, 2403 the LFB class should be 'RedirectSink'. If the message is from CE 2404 to FE, the LFB class should be 'RedirectTap'. 2405 Instance ID: 2406 Instance ID for the 'RedirectSink' LFB or 'RedirectTap' LFB. 2407 Operation TLV: 2408 This is a TLV describing one packet of data to be directed via the 2409 specified LFB above. The order of the data number is also the 2410 order the data packet arrives the redirector LFB, that is, the 2411 Redirected Data #1 should arrive earlier than the Redirected Data 2412 #2 in this redirector LFB. The TLV format is as follows: 2414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2415 | Type = PAYLOAD | Length | 2416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2417 | Path(or Sequence Number?) | 2418 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2419 ~ Redirected Data ~ 2420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 2422 Figure 28 2424 Path(or Sequence Number?): 2425 [Under discussion and TBD] 2426 Type: 2427 [TBD] 2428 Redirected Data: 2429 This field will make a detailed description of the data to be 2430 redirected as well as the data itself. The encoding of the 2431 description is based on the ForCES FE model if the redirector LFB 2432 is defined by FE model, or based on vendor specifications if the 2433 redirector LFB is defined by vendors. The description will 2434 usually include the name (or the name ID) of the redirected packet 2435 data (such as 'IPv4 Packet', 'IPv6 Packet'), and the packet data 2436 itself. It may also include some metadata (metadata name (or name 2437 ID) and its value)associated with the redirected data packet. 2439 6.9 Heartbeat Message 2441 The Heartbeat (HB) Message is used for one ForCES element (FE or CE) 2442 to asynchronously notify one or more other ForCES elements in the 2443 same ForCES NE on its liveness. 2445 A Heartbeat Message is sent by a ForCES element periodically. The 2446 time interval to send the message is set by the Association Setup 2447 Message described in Section 6.1.1. A little different from other 2448 protocol messages, a Heartbeat message is only composed of a common 2449 header, withe the message body left empty. Detailed description of 2450 the message is as below. 2451 Message Transfer Direction: 2452 FE to CE, or CE to FE 2453 Message Header: 2454 The Message Type in the message header is set to MessageType = 2455 'Heartbeat'. The ACK flag in the header SHOULD be set to 2456 'NoACK', meaning no response from receiver(s) is expected by the 2457 message sender. Other values of the ACK flag will always be 2458 ignored by the message receiver. 2460 Message Body: 2461 The message body is empty for the Heartbeat Message. 2463 6.10 Operation Summary 2465 The following tables summarize the operations and their applicabiity 2466 to the messages. 2468 No Operations for the following messages: 2469 Assoc-Setup 2470 Assoc-Setup-Resp 2471 Assoc-Teardown 2472 Heartbeat 2474 +-------------------+-------+------------+--------+-------------+ 2475 | Operation | Query | Query-Resp | Config | config-Resp | 2476 +-------------------+-------+------------+--------+-------------+ 2477 | Set | | | X | X | 2478 | | | | | | 2479 | Delete | | | X | X | 2480 | | | | | | 2481 | Update | | | X | X | 2482 | | | | | | 2483 | Get | X | X | | | 2484 | | | | | | 2485 | Event subscribe | | | X | X | 2486 | | | | | | 2487 | Event unsubscribe | | | X | X | 2488 +-------------------+-------+------------+--------+-------------+ 2490 +-----------+--------------+-------------+------------------+ 2491 | Operation | Packet-Redir | Event-Notif | Event-Notif-Resp | 2492 +-----------+--------------+-------------+------------------+ 2493 | Payload | X | | | 2494 | | | | | 2495 | Event | | X | X | 2496 +-----------+--------------+-------------+------------------+ 2498 7. Protocol Scenarios 2500 7.1 Association Setup state 2502 The associations among CEs and FEs are initiated via Association 2503 setup message from the FE. If a setup request is granted by the CE, 2504 a successful setup response message is sent to the FE. If CEs and 2505 FEs are operating in an insecure environment then the security 2506 association have to be established between them before any 2507 association messages can be exchanged. The TML will take care of 2508 establishing any security associations. 2510 This is followed by capability query, topology query. When the FE is 2511 ready to start forwarding data traffic, it sends a FE UP Event 2512 message to the CE. The CE responds with a FE ACTIVATE State 2513 Maintenance message to ask the FE to go active and start forwarding 2514 data traffic. At this point the association establishment is 2515 complete. These sequences of messages are illustrated in the Figure 2516 below. 2518 FE PL CE PL 2520 | | 2521 | Asso Setup Req | 2522 |---------------------->| 2523 | | 2524 | Asso Setup Resp | 2525 |<----------------------| 2526 | | 2527 | Capability Query | 2528 |<----------------------| 2529 | | 2530 | Query Resp | 2531 |---------------------->| 2532 | | 2533 | Topo Query | 2534 |<----------------------| 2535 | | 2536 | Topo Query Resp | 2537 |---------------------->| 2538 | | 2539 | FE UP Event | 2540 |---------------------->| 2541 | | 2542 | Config-Activate FE | 2543 |<----------------------| 2544 | | 2546 Figure 29: Message exchange between CE and FE to establish an NE 2547 association 2549 On successful completion of this state, the FE joins the NE and is 2550 moved to the Established State or Steady state. 2552 7.2 Association Established state or Steady State 2554 In this state the FE is continously updated or queried. The FE may 2555 also send asynchronous event notifications to the CE or synchronous 2556 heartbeat messages. This continues until a termination (or 2557 deactivation) is initiated by either the CE or FE. Figure below 2558 helps illustrate this state. 2560 FE PL CE PL 2562 | | 2563 | Heart Beat | 2564 |<----------------------| 2565 | | 2566 | Heart Beat | 2567 |---------------------->| 2568 | | 2569 | Config-Subscribe Ev | 2570 |<----------------------| 2571 | | 2572 | Config Resp | 2573 |---------------------->| 2574 | | 2575 | Config-Add LFB Attr | 2576 |<----------------------| 2577 | | 2578 | Config Resp | 2579 |---------------------->| 2580 | | 2581 | Query LFB Stats | 2582 |<----------------------| 2583 | | 2584 | Query Resp | 2585 |---------------------->| 2586 | | 2587 | FE Event Report | 2588 |---------------------->| 2589 | | 2590 | Config-Del LFB Attr | 2591 |<----------------------| 2592 | | 2593 | Config Resp | 2594 |---------------------->| 2595 | | 2596 | Packet Redirect | 2597 |---------------------->| 2598 | | 2599 | Heart Beat | 2600 |<----------------------| 2601 . . 2602 . . 2603 | | 2604 | Config-Activate FE | 2605 |<----------------------| 2606 | | 2608 Figure 30: Message exchange between CE and FE during steady-state 2609 communication 2611 Note that the sequence of messages shown in the figure serve only as 2612 examples and the messages exchange sequences could be different from 2613 what is shown in the figure. Also, note that the protocol scenarios 2614 described in this section do not include all the different message 2615 exchanges which would take place during failover. That is described 2616 in the HA section 8. 2618 8. High Availability Support 2620 The ForCES protocol provides mechanisms for CE redundancy and 2621 failover, in order to support High Availability as defined in 2622 [RFC3654]. FE redundancy and FE to FE interaction is currently out 2623 of scope of this draft. There can be multiple redundant CEs and FEs 2624 in a ForCES NE. However, at any time there can only be one Primary 2625 CE controlling the FEs and there can be multiple secondary CEs. The 2626 FE and the CE PL are aware of the primary and secondary CEs. This 2627 information (primary, secondary CEs) is configured in the FE, CE PLs 2628 during pre-association by FEM, CEM respectively. Only the primary CE 2629 sends Control messages to the FEs. The FE may send its event 2630 reports, redirection packets to only the Primary CE (Report Primary 2631 Mode) or it may send these to both primary and secondary CEs (Report 2632 All Mode). (The latter helps with keeping state between CEs 2633 synchronized, although it does not guarantee synchronization.) This 2634 behavior or HA Modes are configured during Association setup phase 2635 but can be changed by the CE anytime during protocol operation. A 2636 CE-to-CE synchronization protocol will be needed in most cases to 2637 support fast failover, however this will not be defined by the ForCES 2638 protocol. 2640 During a communication failure between the FE and CE (which is caused 2641 due to CE or link reasons, i.e. not FE related), the TML on the FE 2642 will trigger the FE PL regarding this failure. This can also be 2643 detected using the HB messages between FEs and CEs. The FE PL will 2644 send a message (Event Report) to the Secondary CEs to indicate this 2645 failure or the CE PL will detect this and one of the Secondary CEs 2646 takes over as the primary CE for the FE. During this phase, if the 2647 original primary CE comes alive and starts sending any commands to 2648 the FE, the FE should ignore those messages and send an Event to all 2649 CEs indicating its change in Primary CE. Thus the FE only has one 2650 primary CE at a time. 2652 An explicit message (Config message- Move command) from the primary 2653 CE, can also be used to change the Primary CE for an FE during normal 2654 protocol operation. In order to support fast failover, the FE will 2655 establish association (setup msg) as well as complete the capability 2656 exchange with the Primary as well as all the Secondary CEs (in all 2657 scenarios/modes). 2659 These two scenarios (Report All, Report Primary) have been 2660 illustrated in the figures below. 2662 FE CE Primary CE Secondary 2663 | | | 2664 | Asso Estb,Caps exchg | | 2665 1 |<--------------------->| | 2666 | | | 2667 | Asso Estb,Caps|exchange | 2668 2 |<----------------------|------------------->| 2669 | | | 2670 | All msgs | | 2671 3 |<--------------------->| | 2672 | | | 2673 | packet redirection,|events, HBs | 2674 4 |-----------------------|------------------->| 2675 | | | 2676 | FAILURE | 2677 | | 2678 | Event Report (pri CE down) | 2679 5 |------------------------------------------->| 2680 | | 2681 | All Msgs | 2682 6 |------------------------------------------->| 2684 Figure 31: CE Failover for Report All mode 2685 FE CE Primary CE Secondary 2686 | | | 2687 | Asso Estb,Caps exchg | | 2688 1 |<--------------------->| | 2689 | | | 2690 | Asso Estb,Caps|exchange | 2691 2 |<----------------------|------------------->| 2692 | | | 2693 | All msgs | | 2694 3 |<--------------------->| | 2695 | | | 2696 | (HeartBeats| only) | 2697 4 |-----------------------|------------------->| 2698 | | | 2699 | FAILURE | 2700 | | 2701 | Event Report (pri CE down) | 2702 5 |------------------------------------------->| 2703 | | 2704 | All Msgs | 2705 6 |------------------------------------------->| 2707 Figure 32: CE Failover for Report Primary Mode 2709 8.1 Responsibilities for HA 2711 TML level - Transport level: 2712 1. The TML controls logical connection availability and failover. 2713 2. The TML also controls peer HA managements. 2715 At this level, control of all lower layers, for example transport 2716 level (such as IP addresses, MAC addresses etc) and associated links 2717 going down are the role of the TML. 2719 PL Level: 2720 All the other functionality including configuring the HA behavior 2721 during setup, the CEIDs are used to identify primary, secondary CEs, 2722 protocol Messages used to report CE failure (Event Report), Heartbeat 2723 messages used to detect association failure, messages to change 2724 primary CE (config - move), and other HA related operations described 2725 before are the PL responsibility. 2727 To put the two together, if a path to a primary CE is down, the TML 2728 would take care of failing over to a backup path, if one is 2729 available. If the CE is totally unreachable then the PL would be 2730 informed and it will take the appropriate actions described before. 2732 9. Security Considerations 2734 ForCES architecture identified several [Reference Arch] levels of 2735 security. ForCES PL uses security services provided by the ForCES 2736 TML layer. TML layer provides security services such as endpoint 2737 authentication service, message authentication service and 2738 confidentiality service. Endpoint authentication service is invoked 2739 at the time of pre-association connection establishment phase and 2740 message authentication is performed whenever FE or CE receives a 2741 packet from its peer. 2743 Following are the general security mechanism that needs to be in 2744 place for ForCES PL layer. 2745 o Security mechanism are session controlled that is once the 2746 security is turned ON depending upon the chosen security level (No 2747 Security, Authentication only, Confidentiality), it will be in 2748 effect for the entire duration of the session. 2749 o Operator should configure the same security policies for both 2750 primary and backup FE's and CE's (if available). This will ensure 2751 uniform operations, and to avoid unnecessary complexity in policy 2752 configuration. 2753 o ForCES PL endpoints SHOULD pre-established connections with both 2754 primary and backup CE's. This will reduce the security messages 2755 and enable rapid switchover operations for HA. 2757 9.1 No Security 2759 When No security is chosen for ForCES protocol communication, both 2760 endpoint authentication and message authentication service needs be 2761 performed by ForCES PL layer. Both these mechanism are weak and does 2762 not involve cryptographic operation. Operator can choose "No 2763 security" level when the ForCES protocol endpoints are within an 2764 single box. 2766 In order to have interoperable and uniform implementation across 2767 various security levels, each CE and FE endpoint MUST implement this 2768 level. The operations that are being performed for "No security" 2769 level is required even if lower TML security services are being used. 2771 9.1.1 Endpoint Authentication 2773 Each CE and FE PL layer maintain set of associations list as part of 2774 configuration. This is done via CEM and FEM interfaces. FE MUST 2775 connect to only those CE's that are configured via FEM similarly CE 2776 should accept the connection and establish associations for the FE's 2777 which are configured via CEM. CE should validate the FE identifier 2778 before accepting the connection during the pre-association phase. 2780 9.1.2 Message authentication 2782 When CE or FE generates initiates a message, the receiving endpoint 2783 MUST validate the initiator of the message by checking the common 2784 header CE or FE identifiers. This will ensure proper protocol 2785 functioning. We recommend this extra step processing even if the 2786 underlying TLM layer security services. 2788 9.2 ForCES PL and TML security service 2790 This section is applicable if operator wishes to use the TML security 2791 services. ForCES TML layer MUST support one or more security service 2792 such as endpoint authentication service, message authentication 2793 service, confidentiality service as part of TML security layer 2794 functions. It is the responsibility of the operator to select 2795 appropriate security service and configure security policies 2796 accordingly. The details of such configuration is outside the scope 2797 of ForCES PL and is depending upon the type of transport protocol, 2798 nature of connection. 2800 All these configurations should be done prior to starting the CE and 2801 FE. 2803 When certificates-based authentication is being used at TML layer, 2804 the certificate can use ForCES specific naming structure as 2805 certificate names and accordingly the security policies can be 2806 configured at CE and FE. 2808 9.2.1 Endpoint authentication service 2810 When TML security services are enabled. ForCES TML layer performs 2811 endpoint authentication. Security association is established between 2812 CE and FE and is transparent to the ForCES PL layer. 2814 We recommend that FE after establishing the connection with the 2815 primary CE, should establish the security association with the backup 2816 CE (if available). During the switchover operation CE's security 2817 state associated with each SA's are not transferred. SA between 2818 primary CE and FE and backup CE and FE are treated as two separate 2819 SA's. 2821 9.2.2 Message authentication service 2823 This is TML specific operation and is transparent to ForCES PL 2824 layer[TML document]. 2826 9.2.3 Confidentiality service 2828 This is TML specific operation and is transparent to ForCES PL 2829 layer.[TML document] 2831 10. Acknowledgments 2833 The authors of this draft would like to acknowledge and thank the 2834 following: Alex Audu, Steven Blake, Allan DeKok, Ellen M. Deleganes, 2835 Yunfei Guo, Joel M. Halpern, Zsolt Haraszti, Jeff Pickering, 2836 Guangming Wang, Chaoping Wu, Lily L. Yang, and Alistair Munro for 2837 their contributions. We would also like to thank David Putzolu, and 2838 Patrick Droz for their comments and suggestions on the protocol. 2840 11. References 2842 11.1 Normative References 2844 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 2845 June 1999. 2847 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 2848 of IP Control and Forwarding", RFC 3654, November 2003. 2850 [RFC3746] Yang, L., Dantu, R., Anderson, T. and R. Gopal, 2851 "Forwarding and Control Element Separation (ForCES) 2852 Framework", RFC 3746, April 2004. 2854 11.2 Informational References 2856 [ACID] Ha�rder, T. and A. Reuter, "Principles of 2857 Transaction-Orientated Database Recovery", 1983. 2859 [FE-MODEL] 2860 Yang, L., Halpern, J., Gopal, R., DeKok, A., Haraszti, Z. 2861 and S. Blake, "ForCES Forwarding Element Model", Feb. 2862 2005. 2864 Author's Address 2866 Avri Doria 2867 ETRI 2869 Phone: +1 401 663 5024 2870 Email: avri@acm.org 2872 Appendix A. Individual Authors/Editors Contact 2874 Ligang Dong 2875 Zhejiang Gongshang University 2876 149 Jiaogong Road 2877 Hangzhou 310035 2878 P.R.China 2879 Phone: +86-571-88071024 2880 EMail: donglg@mail.hzic.edu.cn 2882 Avri Doria 2883 ETRI 2884 EMail: avri@acm.org 2886 Ram Gopal 2887 Nokia 2888 5, Wayside Road 2889 Burlington MA 01803 2890 USA 2891 Phone: 1-781-993-3685 2892 EMail: ram.gopal@nokia.com 2894 Robert Haas 2895 IBM 2896 Saumerstrasse 4 2897 8803 Ruschlikon 2898 Switzerland 2899 EMail: rha@zurich.ibm.com 2901 Jamal Hadi Salim 2902 Znyx 2903 Ottawa, Ontario 2904 Canada 2905 EMail: hadi@znyx.com 2907 Hormuzd M Khosravi 2908 Intel 2909 2111 NE 25th Avenue 2910 Hillsboro, OR 97124 2911 USA 2912 Phone: +1 503 264 0334 2913 EMail: hormuzd.m.khosravi@intel.com 2914 Weiming Wang 2915 Zhejiang Gongshang University 2916 149 Jiaogong Road 2917 Hangzhou 310035 2918 P.R.China 2919 Phone: +86-571-88057712 2920 EMail: wmwang@mail.hzic.edu.cn 2922 Appendix B. IANA considerations 2924 tbd 2926 Appendix C. Forces Protocol LFB schema 2928 The schema described below conforms to the LFB schema (language?) 2929 described in Forces Model draft[FE-MODEL] 2931 2934 2935 2936 2937 FEPO 2938 1 2939 The FE Protocol Object 2940 1.0 2941 baseclass 2942 2943 2947 2948 HBstate 2949 2 2950 Heartbeat event status(yes/no) 2951 boolean 2952 2953 2954 2956 2957 2958 SupportableVersions 2959 1 2960 the table of ForCES versions that FE supports 2961 2962 u8 2963 2964 2965 2966 2970 2971 2972 HBI 2973 3 2974 Heartbeat Interval in millisecs 2975 uint32 2976 2977 2978 HBDI 2979 4 2980 Heartbeat Dead Interval in millisecs 2981 uint32 2982 2983 2984 CurrentRunningVersion 2985 5 2986 Currently running ForCES version 2987 u8 2988 2989 2990 2992 2993 2994 2996 C.1 Events 2998 At the moment only one event, HBstate, can be subscribed to by the 2999 CE. 3001 By subscribing to the HBstate event, the CE infact kicks the FE into 3002 motion to start issuing heartbeats. 3004 C.2 Capabilities 3006 At the moment only the SupportableVersions capability is owned by 3007 this LFB. 3009 SupportableVersions enumerates all ForCES versions that an FE 3010 supports. 3012 C.3 Attributes 3014 C.3.1 HBI 3016 This attribute carries the Heartbeat Interval of the heartbeat from 3017 the FE -> CE in millisecs. The value of this interval is by default 3018 set by the FE but could be overwritten in the association setup by 3019 the CE. 3021 TBD (this really belongs in the protocol draft but here for capture 3022 purposes: 3024 Define it as simply that the CE and FE must hear from each other at 3025 the configured interval. The FE on her side generates a heartbeat 3026 notification if he has nothing else to say. In otehr words, The lack 3027 of any messages from the CE to which the FE responded to after a 3028 period of HBI will result in a FE firing a HB message. The lack of 3029 any message within DeadInterval will force the FE to ask for an ACK 3030 for its HB message (by setting the ACK flag in the header). 3032 Other adaptive heartbeats schemes which could be used: have the CE 3033 adjust the FE timers depending on the number of FEs present. 3034 Example, its 1 sec for upto 100 FEs and 2 seconds for [101,200] 4 3035 seconds interval for > 200 nodes etc ... Some adaptation of this is 3036 used by mmusic mbus protocol. 3038 C.3.2 HBDI 3040 This attribute carries the Heartbeat Dead Interval in millisecs. 3042 TBD: 3044 The original goal for HBDI was for HA purposes - to discover if the 3045 CE is still around by sending a heartbeat message to the CE with an 3046 ACK flag in the mainheader to request for a response. This hasnt 3047 been discussed in details yet; however, the general view at the time 3048 was for the FE to associate (failover) to another CE after that 3049 deadinterval period of not hearing from the CE - as defined by policy 3050 which resides in that same LFB definition. Two such failover 3051 methodologies are mentiooned briefly infact in the protocol draft but 3052 since the current attributes are unknown, the details are missing 3053 from the xml. 3055 C.3.3 CurrentRunningVersion 3057 This attribute describes which version of ForCES is currently 3058 running. 3060 Appendix D. Use Cases 3062 Assume LFB with following attributes for the following use cases. 3064 foo1, type u32, ID = 1 3066 foo2, type u32, ID = 2 3068 table1: type array, ID = 3 3069 elements are: 3070 t1, type u32, ID = 1 3071 t2, type u32, ID = 2 // index into table 2 3072 KEY: nhkey, ID = 1, V = t2 3074 table2: type array, ID = 4 3075 elements are: 3076 j1, type u32, ID = 1 3077 j2, type u32, ID = 2 3078 KEY: akey, ID = 1, V = { j1,j2 } 3080 table3: type array, ID = 5 3081 elements are: 3082 someid, type u32, ID = 1 3083 name, type string variable sized, ID = 2 3085 table4: type array, ID = 6 3086 elements are: 3087 j1, type u32, ID = 1 3088 j2, type u32, ID = 2 3089 j3, type u32, ID = 3 3090 j4, type u32, ID = 4 3091 KEY: mykey, ID = 1, V = { j1} 3093 table5: type array, ID = 7 3094 elements are: 3095 p1, type u32, ID = 1 3096 p2, type array, ID = 2, array elements of type-X 3098 Type-X: 3099 x1, ID 1, type u32 3100 x2, ID2 , type u32 3101 KEY: tkey, ID = 1, V = { x1} 3103 All examples will show an attribute suffixed with "v" or "val" to 3104 indicate the value of the referenced attribute. example for 3105 attribute foo2, foo1v or foo1value will indicate the value of foo1. 3106 In the case where F_SEL** are missing (bits equal to 00) then the 3107 flags will not show any selection. 3109 1. To get foo1 3111 OPER = GET-TLV 3112 Path-data TLV: IDCount = 1, IDs = 1 3113 Result: 3114 OPER = GET-RESPONSE-TLV 3115 Path-data-TLV: 3116 flags=0, IDCount = 1, IDs = 1 3117 DATARAW-TLV L = 4+4, V = foo1v 3119 2. To set foo2 to 10 3121 OPER = SET-REPLACE-TLV 3122 Path-data-TLV: 3123 flags = 0, IDCount = 1, IDs = 2 3124 DATARAW TLV: L = 4+4, V=10 3126 Result: 3127 OPER = SET-RESPONSE-TLV 3128 Path-data-TLV: 3129 flags = 0, IDCount = 1, IDs = 2 3130 RESULT-TLV 3132 3. To dump table2 3134 OPER = GET-TLV 3135 Path-data-TLV: 3136 IDCount = 1, IDs = 4 3137 Result: 3138 OPER = GET-RESPONSE-TLV 3139 Path-data-TLV: 3140 flags = 0, IDCount = 1, IDs = 4 3141 DATARAW=TLV: L = XXX, V= 3142 a series of: index, j1value,j2value entries 3143 representing the entire table 3145 Note: One should be able to take a GET-RESPONSE-TLV and convert it 3146 to a SET-REPLACE-TLV. 3147 If the result in the above example is sent back in a SET-REPLACE-TLV, 3148 (instead of a GET-RESPONSE_TLV) then the entire contents of the table 3149 will be replaced at that point. 3151 4. Multiple operations Example. To create entry 0-5 of table2 3152 (Ignore error conditions for now) 3154 OPER = SET-CREATE-TLV 3155 Path-data-TLV: 3156 flags = 0 , IDCount = 1, IDs=4 3157 PATH-DATA-TLV 3158 flags = 0, IDCount = 1, IDs = 0 3159 DATARAW-TLV containing j1, j2 value for entry 0 3160 PATH-DATA-TLV 3161 flags = 0, IDCount = 1, IDs = 1 3162 DATARAW-TLV containing j1, j2 value for entry 1 3163 PATH-DATA-TLV 3164 flags = 0, IDCount = 1, IDs = 2 3165 DATARAW-TLV containing j1, j2 value for entry 2 3166 PATH-DATA-TLV 3167 flags = 0, IDCount = 1, IDs = 3 3168 DATARAW-TLV containing j1, j2 value for entry 3 3169 PATH-DATA-TLV 3170 flags = 0, IDCount = 1, IDs = 4 3171 DATARAW-TLV containing j1, j2 value for entry 4 3172 PATH-DATA-TLV 3173 flags = 0, IDCount = 1, IDs = 5 3174 DATARAW-TLV containing j1, j2 value for entry 5 3176 Result: 3177 OPER = SET-RESPONSE-TLV 3178 Path-data-TLV: 3179 flags = 0 , IDCount = 1, IDs=4 3180 PATH-DATA-TLV 3181 flags = 0, IDCount = 1, IDs = 0 3182 RESULT-TLV 3183 PATH-DATA-TLV 3184 flags = 0, IDCount = 1, IDs = 1 3185 RESULT-TLV 3186 PATH-DATA-TLV 3187 flags = 0, IDCount = 1, IDs = 2 3188 RESULT-TLV 3189 PATH-DATA-TLV 3190 flags = 0, IDCount = 1, IDs = 3 3191 RESULT-TLV 3192 PATH-DATA-TLV 3193 flags = 0, IDCount = 1, IDs = 4 3194 RESULT-TLV 3195 PATH-DATA-TLV 3196 flags = 0, IDCount = 1, IDs = 5 3197 RESULT-TLV 3199 5. Block operations (with holes) example. Replace entry 0,2 of 3200 table2 3202 OPER = SET-REPLACE-TLV 3203 Path-data TLV: 3204 flags = 0 , IDCount = 1, IDs=4 3205 PATH-DATA-TLV 3206 flags = 0, IDCount = 1, IDs = 0 3207 DATARAW-TLV containing j1, j2 value for entry 0 3208 PATH-DATA-TLV 3209 flags = 0, IDCount = 1, IDs = 2 3210 DATARAW-TLV containing j1, j2 value for entry 2 3212 Result: 3213 OPER = SET-REPLACE-TLV 3214 Path-data TLV: 3215 flags = 0 , IDCount = 1, IDs=4 3216 PATH-DATA-TLV 3217 flags = 0, IDCount = 1, IDs = 0 3218 RESULT-TLV 3219 PATH-DATA-TLV 3220 flags = 0, IDCount = 1, IDs = 2 3221 RESULT-TLV 3223 6. Getting rows example. Get first entry of table2. 3225 OPER = GET-TLV 3226 Path-data TLV: 3227 IDCount = 2, IDs=4.0 3229 Result: 3230 OPER = GET-RESPONSE-TLV 3231 Path-data TLV: 3232 IDCount = 2, IDs=4.0 3233 DATARAW TLV, Length = XXX, V = 3234 j1value,j2value entry 3236 7. Get entry 0-5 of table2. 3238 OPER = GET-TLV 3239 Path-data-TLV: 3240 flags = 0, IDCount = 1, IDs=4 3241 PATH-DATA-TLV 3242 flags = 0, IDCount = 1, IDs = 0 3243 PATH-DATA-TLV 3244 flags = 0, IDCount = 1, IDs = 1 3245 PATH-DATA-TLV 3246 flags = 0, IDCount = 1, IDs = 2 3247 PATH-DATA-TLV 3248 flags = 0, IDCount = 1, IDs = 3 3249 PATH-DATA-TLV 3250 flags = 0, IDCount = 1, IDs = 4 3251 PATH-DATA-TLV 3252 flags = 0, IDCount = 1, IDs = 5 3254 Result: 3255 OPER = GET-RESPONSE-TLV 3256 Path-data-TLV: 3257 flags = 0, IDCount = 1, IDs=4 3258 PATH-DATA-TLV 3259 flags = 0, IDCount = 1, IDs = 0 3260 DATARAW-TLV containing j1value j2value 3261 PATH-DATA-TLV 3262 flags = 0, IDCount = 1, IDs = 1 3263 DATARAW-TLV containing j1value j2value 3264 PATH-DATA-TLV 3265 flags = 0, IDCount = 1, IDs = 2 3266 DATARAW-TLV containing j1value j2value 3267 PATH-DATA-TLV 3268 flags = 0, IDCount = 1, IDs = 3 3269 DATARAW-TLV containing j1value j2value 3270 PATH-DATA-TLV 3271 flags = 0, IDCount = 1, IDs = 4 3272 DATARAW-TLV containing j1value j2value 3273 PATH-DATA-TLV 3274 flags = 0, IDCount = 1, IDs = 5 3275 DATARAW-TLV containing j1value j2value 3277 8. Create a row in table2, index 5. 3279 OPER = SET-CREATE-TLV 3280 Path-data-TLV: 3281 flags = 0, IDCount = 2, IDs=4.5 3282 DATARAW TLV, Length = XXX 3283 j1value,j2value 3285 Result: 3286 OPER = SET-RESPONSE-TLV 3287 Path-data TLV: 3288 flags = 0, IDCount = 1, IDs=4.5 3289 RESULT-TLV 3291 9. An example of "create and give me an index" Assuming we asked for 3292 verbose response back in the main message header. 3294 OPER = SET-CREATE-TLV 3295 Path-data -TLV: 3296 flags = FIND-EMPTY, IDCount = 1, IDs=4 3297 DATARAW TLV, Length = XXX 3298 j1value,j2value 3300 Result 3301 If 7 were the first unused entry in the table: 3302 OPER = SET-RESPONSE 3303 Path-data TLV: 3304 flags = 0, IDCount = 2, IDs=4.7 3305 RESULT-TLV indicating success, and 3306 DATARAW-TLV, Length = XXX j1value,j2value 3308 10. Dump contents of table1. 3310 OPER = GET-TLV 3311 Path-data TLV: 3312 flags = 0, IDCount = 1, IDs=3 3314 Result: 3315 OPER = GET-RESPONSE-TLV 3316 Path-data TLV 3317 flags = 0, IDCount = 1, IDs=3 3318 DATARAW TLV, Length = XXXX (depending on size of table1) 3319 index, t1value, t2value 3320 index, t1value, t2value 3321 . 3322 . 3324 . 3326 11. Using Keys. Get row entry from table4 where j1=100. Recall, j1 3327 is a defined key for this table and its keyid is 1. 3329 NOTE! NOTE! 3330 There is still debate as to whether this must reference only 1 entry. 3332 OPER = GET-TLV 3333 Path-data-TLV: 3334 flags = F_SELKEY IDCount = 1, IDs=6 3335 KEYINFO-TLV = KEYID=1, KEY_DATA=100 3337 Result: 3338 If j1=100 was at index 10 3339 OPER = GET-RESPONSE-TLV 3340 Path-data TLV: 3341 flags = 0, IDCount = 1, IDs=6.10 3342 DATARAW TLV, Length = XXXX 3343 j1value,j2value, j3value, j4value 3345 12. Delete row with KEY match (j1=100, j2=200) in table 2. Note 3346 that the j1,j2 pair are a defined key for the table 2. 3348 OPER = DEL-TLV 3349 Path-data TLV: 3350 flags = F_SELKEY IDCount = 1, IDs=4 3351 KEYINFO TLV: {KEYID =1 KEY_DATA=100,200} 3353 Result: 3354 If (j1=100, j2=200) was at entry 15: 3355 OPER = DELETE-RESPONSE-TLV 3356 Path-data TLV: 3357 flags = 0 IDCount = 2, IDs=4.15 3358 RESULT-TLV (with DATARAW if verbose) 3360 13. Dump contents of table3. It should be noted that this table has 3361 a column with element name that is variable sized. The purpose 3362 of this use case is to show how such an element is to be 3363 encoded. 3365 OPER = GET-TLV 3366 Path-data-TLV: 3367 flags = 0 IDCount = 1, IDs=5 3369 Result: 3370 OPER = GET-RESPONSE-TLV 3371 Path-data TLV: 3372 flags = 0 IDCount = 1, IDs=5 3373 DATARAW TLV, Length = XXXX 3374 index, someidv, TLV: T=DATARAW, L = 4+strlen(namev), V = namev 3375 index, someidv, TLV: T=DATARAW, L = 4+strlen(namev), V = namev 3376 index, someidv, TLV: T=DATARAW, L = 4+strlen(namev), V = namev 3377 index, someidv, TLV: T=DATARAW, L = 4+strlen(namev), V = namev 3378 . 3379 . 3380 . 3382 14. Multiple atomic operations. 3384 [This emulates adding a new nexthop entry and then atomically 3385 updating the L3 entries pointing to an old NH to point to a new 3386 one. The assumption is both tables are in the same LFB] 3388 Main header has atomic flag set and we are request for 3389 verbose/full results back; 3390 Two operations on the LFB instance, both are SET operations. 3392 //Operation 1: Add a new entry to table2 index #20. 3393 OPER = SET-CREATE-TLV 3394 Path-TLV: 3395 flags = 0, IDCount = 2, IDs=4.20 3396 DATARAW TLV, V= j1value,j2value 3398 // Operation 2: Update table1 entry which 3399 // was pointing with t2 = 10 to now point to 20 3400 OPER = SET-REPLACE-TLV 3401 Path-data-TLV: 3402 flags = F_SELKEY, IDCount = 1, IDs=3 3403 KEYINFO = KEYID=1 KEY_DATA=10 3404 Path-data-TLV 3405 flags = 0 IDCount = 1, IDs=2 3406 DATARAW TLV, V= 20 3408 Result: 3409 //first operation, SET 3410 OPER = SET-RESPONSE-TLV 3411 Path-data-TLV 3412 flags = 0 IDCount = 3, IDs=4.20 3413 RESULT-TLV code = success 3414 DATARAW TLV, V = j1value,j2value 3415 // second opertion SET - assuming entry 16 was updated 3416 OPER = SET-RESPONSE-TLV 3417 Path-data TLV 3418 flags = 0 IDCount = 2, IDs=3.16 3419 Path-Data TLV 3420 flags = 0 IDCount = 1, IDs = 2 3421 SET-RESULT-TLV code = success 3422 DATARAW TLV, Length = XXXX v=20 3423 // second opertion SET 3424 OPER = SET-RESPONSE-TLV 3425 Path-data TLV 3426 flags = 0 IDCount = 1, IDs=3 3427 KEYINFO = KEYID=1 KEY_DATA=10 3428 Path-Data TLV 3429 flags = 0 IDCount = 1, IDs = 2 3430 SET-RESULT-TLV code = success 3431 DATARAW TLV, Length = XXXX v=20 3433 15. Selective setting (Example posted by Weiming). On table 4 -- 3434 for indices 1, 3, 5, 7, and 9. Replace j1 to 100, j2 to 200, j3 3435 to 300. Leave j4 as is. 3437 PER = SET-REPLACE-TLV 3438 Path-data TLV 3439 flags = 0, IDCount = 1, IDs = 6 3440 Path-data TLV 3441 flags = 0, IDCount = 1, IDs = 1 3442 Path-data TLV 3443 flags = 0, IDCount = 1, IDs = 1 3444 DATARAW TLV, Length = XXXX, V = {100} 3445 Path-data TLV 3446 flags = 0, IDCount = 1, IDs = 2 3447 DATARAW TLV, Length = XXXX, V = {200} 3448 Path-data TLV 3449 flags = 0, IDCount = 1, IDs = 3 3450 DATARAW TLV, Length = XXXX, V = {300} 3451 Path-data TLV 3452 flags = 0, IDCount = 1, IDs = 3 3453 Path-data TLV 3454 flags = 0, IDCount = 1, IDs = 1 3455 DATARAW TLV, Length = XXXX, V = {100} 3456 Path-data TLV 3457 flags = 0, IDCount = 1, IDs = 2 3458 DATARAW TLV, Length = XXXX, V = {200} 3459 Path-data TLV 3460 flags = 0, IDCount = 1, IDs = 3 3461 DATARAW TLV, Length = XXXX, V = {300} 3462 Path-data TLV 3463 flags = 0, IDCount = 1, IDs = 5 3464 Path-data TLV 3465 flags = 0, IDCount = 1, IDs = 1 3466 DATARAW TLV, Length = XXXX, V = {100} 3467 Path-data TLV 3468 flags = 0, IDCount = 1, IDs = 2 3469 DATARAW TLV, Length = XXXX, V = {200} 3470 Path-data TLV 3471 flags = 0, IDCount = 1, IDs = 3 3472 DATARAW TLV, Length = XXXX, V = {300} 3473 Path-data TLV 3474 flags = 0, IDCount = 1, IDs = 7 3475 Path-data TLV 3476 flags = 0, IDCount = 1, IDs = 1 3477 DATARAW TLV, Length = XXXX, V = {100} 3478 Path-data TLV 3479 flags = 0, IDCount = 1, IDs = 2 3480 DATARAW TLV, Length = XXXX, V = {200} 3481 Path-data TLV 3482 flags = 0, IDCount = 1, IDs = 3 3483 DATARAW TLV, Length = XXXX, V = {300} 3484 Path-data TLV 3485 flags = 0, IDCount = 1, IDs = 9 3486 Path-data TLV 3487 flags = 0, IDCount = 1, IDs = 1 3488 DATARAW TLV, Length = XXXX, V = {100} 3489 Path-data TLV 3490 flags = 0, IDCount = 1, IDs = 2 3491 DATARAW TLV, Length = XXXX, V = {200} 3492 Path-data TLV 3493 flags = 0, IDCount = 1, IDs = 3 3494 DATARAW TLV, Length = XXXX, V = {300} 3496 Non-verbose response mode shown: 3498 OPER = SET-RESPONSE-TLV 3499 Path-data TLV 3500 flags = 0, IDCount = 1, IDs = 6 3501 Path-data TLV 3502 flags = 0, IDCount = 1, IDs = 1 3503 Path-data TLV 3504 flags = 0, IDCount = 1, IDs = 1 3505 RESULT-TLV 3506 Path-data TLV 3507 flags = 0, IDCount = 1, IDs = 2 3508 RESULT-TLV 3509 Path-data TLV 3510 flags = 0, IDCount = 1, IDs = 3 3511 RESULT-TLV 3512 Path-data TLV 3513 flags = 0, IDCount = 1, IDs = 3 3514 Path-data TLV 3515 flags = 0, IDCount = 1, IDs = 1 3516 RESULT-TLV 3517 Path-data TLV 3518 flags = 0, IDCount = 1, IDs = 2 3519 RESULT-TLV 3520 Path-data TLV 3521 flags = 0, IDCount = 1, IDs = 3 3522 RESULT-TLV 3523 Path-data TLV 3524 flags = 0, IDCount = 1, IDs = 5 3525 Path-data TLV 3526 flags = 0, IDCount = 1, IDs = 1 3527 RESULT-TLV 3528 Path-data TLV 3529 flags = 0, IDCount = 1, IDs = 2 3530 RESULT-TLV 3531 Path-data TLV 3532 flags = 0, IDCount = 1, IDs = 3 3533 RESULT-TLV 3534 Path-data TLV 3535 flags = 0, IDCount = 1, IDs = 7 3536 Path-data TLV 3537 flags = 0, IDCount = 1, IDs = 1 3538 RESULT-TLV 3539 Path-data TLV 3540 flags = 0, IDCount = 1, IDs = 2 3541 RESULT-TLV 3542 Path-data TLV 3543 flags = 0, IDCount = 1, IDs = 3 3544 RESULT-TLV 3545 Path-data TLV 3546 flags = 0, IDCount = 1, IDs = 9 3547 Path-data TLV 3548 flags = 0, IDCount = 1, IDs = 1 3549 RESULT-TLV 3550 Path-data TLV 3551 flags = 0, IDCount = 1, IDs = 2 3552 RESULT-TLV 3554 Path-data TLV 3555 flags = 0, IDCount = 1, IDs = 3 3556 RESULT-TLV 3558 16. Manipulation of table of table examples. Get x1 from table10 3559 row with index 4, inside table5 entry 10 3561 operation = GET-TLV 3562 Path-data-TLV 3563 flags = 0 IDCount = 5, IDs=7.10.2.4.1 3565 Results: 3566 operation = GET-RESPONSE-TLV 3567 Path-data-TLV 3568 flags = 0 IDCount = 5, IDs=7.10.2.4.1 3569 DATARAW TLV: L=XXXX, V = {x1 value} 3571 17. From table5's row 10 table10, get X2s based on on the value of 3572 x1 equlaing 10 (recal x1 is KeyID 1) 3574 operation = GET-TLV 3575 Path-data-TLV 3576 flag = F_SELKEY, IDCount=3, IDS = 7.10.2 3577 KEYINFO TLV, KEYID = 1, KEYDATA = 10 3578 Path-data TLV 3579 IDCount = 1, IDS = 2 //select x2 3581 Results: 3582 If x1=10 was at entry 11: 3583 operation = GET-RESPONSE-TLV 3584 Path-data-TLV 3585 flag = 0, IDCount=5, IDS = 7.10.2.11 3586 Path-data TLV 3587 flags = 0 IDCount = 1, IDS = 2 3588 DATARAW TLV: L=XXXX, V = {x2 value} 3590 18. Further example of table of table 3592 Weiming would like to update different items on a hierachy of data. 3593 So this example is there to show how that can be done with the 3594 current BNF. 3596 Consider table 6 which is defined as: 3597 table6: type array, ID = 8 3598 elements are: 3600 p1, type u32, ID = 1 3601 p2, type array, ID = 2, array elements of type type-A 3603 type-A: 3604 a1, type u32, ID 1, 3605 a2, type array ID2 ,array elements of type type-B 3607 type-B: 3608 b1, type u32, ID 1 3609 b2, type u32, ID 2 3611 So lets say we wanted to set by replacing: 3612 table6.10.p1 to 111 3613 table6.10.p2.20.a1 to 222 3614 table6.10.p2.20.a2.30.b1 to 333 3616 in one message and one operation. 3618 There are two ways to do this: 3619 a) using nesting 3621 operation = SET-REPLACE-TLV 3622 Path-data-TLV 3623 flags = 0 IDCount = 2, IDs=6.10 3624 Path-data-TLV 3625 flags = 0, IDCount = 1, IDs=1 3626 DATARAW TLV: L=XXXX, 3627 V = {111} 3628 Path-data-TLV 3629 flags = 0 IDCount = 2, IDs=2.20 3630 Path-data-TLV 3631 flags = 0, IDCount = 1, IDs=1 3632 DATARAW TLV: L=XXXX, 3633 V = {222} 3634 Path-data TLV : 3635 flags = 0, IDCount = 3, IDs=2.30.1 3636 DATARAW TLV: L=XXXX, 3637 V = {333} 3638 Result: 3639 operation = SET-RESPONSE-TLV 3640 Path-data-TLV 3641 flags = 0 IDCount = 2, IDs=6.10 3642 Path-data-TLV 3643 flags = 0, IDCount = 1, IDs=1 3644 RESULT-TLV 3645 Path-data-TLV 3646 flags = 0 IDCount = 2, IDs=2.20 3647 Path-data-TLV 3648 flags = 0, IDCount = 1, IDs=1 3649 RESULT-TLV 3650 Path-data TLV : 3651 flags = 0, IDCount = 3, IDs=2.30.1 3652 RESULT-TLV 3653 b) using a flat path data 3654 operation = SET-REPLACE-TLV 3655 Path-data TLV : 3656 flags = 0, IDCount = 3, IDs=6.10.1 3657 DATARAW TLV: L=XXXX, 3658 V = {111} 3659 Path-data TLV : 3660 flags = 0, IDCount = 5, IDs=6.10.1.20.1 3661 DATARAW TLV: L=XXXX, 3662 V = {222} 3663 Path-data TLV : 3664 flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1 3665 DATARAW TLV: L=XXXX, 3666 V = {333} 3667 Result: 3668 operation = SET-REPLACE-TLV 3669 Path-data TLV : 3670 flags = 0, IDCount = 3, IDs=6.10.1 3671 RESULT-TLV 3672 Path-data TLV : 3673 flags = 0, IDCount = 5, IDs=6.10.1.20.1 3674 RESULT-TLV 3675 Path-data TLV : 3676 flags = 0, IDCount = 7, IDs=6.10.1.20.1.30.1 3677 RESULT-TLV 3679 19. Get a whole LFB (all its attributes etc). 3681 For example, at startup a CE might well want the entire FE OBJECT LFB. 3682 So, in a request targetted at class 1, instance 1, one might find: 3684 operation = GET-TLV 3685 Path-data-TLV 3686 flags = 0 IDCount = 0 3688 result: 3689 operation = GET-RESPONSE-TLV 3690 Path-data-TLV 3691 flags = 0 IDCount = 0 3692 DATARAW encoding of the FE Object LFB 3694 Appendix E. Implementation Notes 3696 E.1 TML considerations 3698 Having separated the PL from the TML layer, it became clear that the 3699 TML layer needed to understand the desires of the PL layer to service 3700 it. Example: How does the TML layer map prioritization or 3701 reliability needs of a PL message? To see the challenge involved, 3702 assume that all of the FE TML, FE PL, CE TML and CE PL are 3703 implemented by different authors probably belonging to different 3704 organizations. Three implementation alternatives were discussed. 3706 As an example, consider a TML which defines that PL messages needing 3707 reliability get sent over a TCP connection; then TML-PL interfaces 3708 are: 3709 o PL to call a special API: example send_reliable(msg) which is 3710 translated by the TML to mean send via TCP. 3711 o PL to call a generic API: example send(msg) with explicit msg 3712 flags turned to say "reliability needed" and the TML translates 3713 this to mean send via TCP. 3714 o PL sends the Forces Messages such a message is inferred to mean 3715 send via TCP by the TML. 3717 in #1 and #2 the msg includes a ForCES msg with metadata flags which 3718 are consumed by the TML layer. 3720 #3 is a technique that will be referred as inference-by-TML 3721 technique. It simplifies the standardization effort since both #1 3722 and #2 will require standardization of an API. Two ideas discussed 3723 for TML inference of PL messages are: 3724 1. Looking at the flags in the header. 3725 2. Looking at the message type. 3727 #1 and #2 can still be used if a single organization implements both 3728 (PL and TML) layers. It is also reasonable that one organization 3729 implements the TML and provides an abstraction to another 3730 organization to implement a PL layer on. 3732 E.1.1 PL Flag inference by TML 3733 1. Reliability 3734 This could be "signalled" from the PL to the TML via the ACK 3735 flag. The message type as well could be used to indicate this. 3736 2. No reliability 3737 Could be signalled via missing ACK flag. The message type as 3738 well could be used to indicate this. 3739 3. Priorities 3740 A remapping to be defined via the FEM or the CEM interface 3741 depending on the number of TML priorities available. 3743 4. Addressing 3744 This is TML specific. For example a TML that is capable of 3745 multicast transport may map a multicast PL ID to a multicast 3746 transport address. 3747 5. Event notifications 3748 The TML must be able to send to the PL notifications. 3749 1. The TML should be able to send Transport level congestion 3750 notifications to the PL. 3751 2. Link events for HA purposes if configuration requires it 3752 3. Events that will trigger PL layer events from the TML. 3753 As an example, an HA event at the TML layer like a failure of 3754 CE detected at TML on the FE may belong to this. In this 3755 case, a PL event msg will be triggered and sent to CE. 3756 4. Events that are intrinsic to the same CE or FE a TML is 3757 located. These will not trigger any PL msg, instead, they 3758 just act as notification to PL core (FE object). The 3759 congestion event generated at the transmission source side 3760 may belong to this, because it usually only needs to tell the 3761 upper PL at the same side rather than the opposite side that 3762 congestion has happened along the path. E.g., a congestion 3763 event at CE TML layer only need to tell CE PL of this, rather 3764 than the opposite FE via a PL msg. 3766 E.1.2 Message type inference to Mapping at the TML 3768 In this case one would define the desires of the different message 3769 types and what they expect from the TML. For example: 3770 1. Association Setup, Teardown, Config, Query the PL will expect the 3771 following services from TML: Reliable delivery and highest 3772 prioritization. 3773 2. Packet Redirect, HB Message Types, and Event Reports the PL will 3774 require the following services from TML: Medium Prioritization, 3775 and notifications when excessive losses are reached. 3777 Appendix F. Changes between -01 and -02 3778 1. Renamed definitions.xml to Definitions.xml 3779 2. Added Alistair Munro to acks list. 3780 3. path-data additions + full BNF conformant to RFC 2234 3781 4. Appendix C with examples. #3 and #4 are the biggest changes 3782 incorporate many many days of discussion. 3783 5. appendix with beginings of FE protocol LFB xml. The FE Object is 3784 referenced as being in the Model draft 3785 6. Some cosmetic things like: 3786 1. For readability, introducing section 'protocol construction' 3787 which now encapsulates 'Protocol Messages' (which used to be 3788 a top section) 3789 2. A new subsection "protocol grammar' goes underneath the same 3790 section. 3791 3. added TLV definition subsection 3792 4. Many new "editorial notes" 3793 7. Closure of all but one outstanding issue from the tracker. 3794 8. Any other cosmetic changes posted (Hormuzd, David, Robert, Avri). 3795 9. Rearranged text a little to introduce new sections to make text 3796 more readable 3797 10. Rewrote the atomicity section (still under construction input 3798 text on ACID from Robert and Alistair) 3799 11. fixed up the model reference to have all authors and added acid 3800 reference 3801 12. Weiming's updates to query and event msgs to add path-data. 3803 Appendix G. Changes between -00 and -01 3804 1. Major Protocol changes 3805 * Restructured message format to apply operation to LFB as 3806 opposed to having operation be the primary organizing 3807 principle 3808 * Worked with model team to bring the draft into harmony with 3809 their model approach 3810 2. Document changes 3811 * Replaced FE protocol Object and FE Object sections with 3812 combined section on FE, CE and FE protocol LFBs 3813 * Removed minor version id 3814 * Added Header flags 3815 * Added BNF description of message structure 3816 * Added tree structure description of PDUs 3817 * Added section on each type of LFB 3818 * Added structural description of each message 3819 * Moved query messages section to come after config message 3820 section 3821 * Replace state maintenance section 3822 * Added section with tables showing the operations relevant to 3823 particular messages 3824 * Reworked HA section 3825 * Many spelling and grammatical corrections 3827 Intellectual Property Statement 3829 The IETF takes no position regarding the validity or scope of any 3830 Intellectual Property Rights or other rights that might be claimed to 3831 pertain to the implementation or use of the technology described in 3832 this document or the extent to which any license under such rights 3833 might or might not be available; nor does it represent that it has 3834 made any independent effort to identify any such rights. Information 3835 on the procedures with respect to rights in RFC documents can be 3836 found in BCP 78 and BCP 79. 3838 Copies of IPR disclosures made to the IETF Secretariat and any 3839 assurances of licenses to be made available, or the result of an 3840 attempt made to obtain a general license or permission for the use of 3841 such proprietary rights by implementers or users of this 3842 specification can be obtained from the IETF on-line IPR repository at 3843 http://www.ietf.org/ipr. 3845 The IETF invites any interested party to bring to its attention any 3846 copyrights, patents or patent applications, or other proprietary 3847 rights that may cover technology that may be required to implement 3848 this standard. Please address the information to the IETF at 3849 ietf-ipr@ietf.org. 3851 Disclaimer of Validity 3853 This document and the information contained herein are provided on an 3854 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 3855 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 3856 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 3857 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 3858 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 3859 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 3861 Copyright Statement 3863 Copyright (C) The Internet Society (2005). This document is subject 3864 to the rights, licenses and restrictions contained in BCP 78, and 3865 except as set forth therein, the authors retain all their rights. 3867 Acknowledgment 3869 Funding for the RFC Editor function is currently provided by the 3870 Internet Society.