idnits 2.17.1 draft-ietf-forces-protocol-00.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 3667, Section 5.1 on line 13. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2372. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2349. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2356. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2362. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 2378), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** There are 7 instances of lines with control characters in the document. ** 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 603: '...nt for a transaction MUST be met. The...' RFC 2119 keyword, line 619: '...se default values MUST be used for the...' RFC 2119 keyword, line 839: '...tive, a particular multicast ID MAY be...' RFC 2119 keyword, line 841: '... delivered to such a multicast ID MUST...' RFC 2119 keyword, line 1053: '...ag in the header SHOULD be set 'ACKAll...' (11 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 25, 2004) is 7153 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: 'TBD' is mentioned on line 1750, but not defined == Unused Reference: 'RFC2629' is defined on line 2206, 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: 12 errors (**), 0 flaws (~~), 4 warnings (==), 8 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: March 26, 2005 September 25, 2004 5 ForCES Protocol Specification 6 draft-ietf-forces-protocol-00.txt 8 Status of this Memo 10 By submitting this Internet-Draft, I certify that any applicable 11 patent or other IPR claims of which I am aware have been disclosed, 12 and any of which I become aware will be disclosed, in accordance with 13 RFC 3668. 15 Internet-Drafts are working documents of the Internet Engineering 16 Task Force (IETF), its areas, and its working groups. Note that 17 other groups may also distribute working documents as 18 Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 The list of current Internet-Drafts can be accessed at 26 http://www.ietf.org/ietf/1id-abstracts.txt. 28 The list of Internet-Draft Shadow Directories can be accessed at 29 http://www.ietf.org/shadow.html. 31 This Internet-Draft will expire on March 26, 2005. 33 Copyright Notice 35 Copyright (C) The Internet Society (2004). All Rights Reserved. 37 Abstract 39 This specification documents the Forwarding and Control Element 40 Seperation protocol. This protocol is desgined to be used between a 41 Control Element and a Forwarding Element in a Routing Network 42 Element. 44 Authors 46 The participants in the ForCES Protocol Team, authors and co-editors, 47 of this draft, are: 49 Ligang Dong, Zhejiang Gongshang University 50 Avri Doria, ETRI 51 Ram Gopal, Nokia 52 Robert Haas, IBM 53 Jamal Hadi Salim, Znyx 54 Hormuzd M Khosravi, Intel 55 Weiming Wang, Zhejiang Gongshang University 57 Acknowledgment 59 The authors of this draft would like to acknowledge and thank all the 60 protocol proposal authors including Alex Audu, Steven Blake, Chaoping 61 Wu, Jeff Pickering, Yunfei Guo, and Guangming Wang for their 62 contributions. We would also like to thank David Putzolu, and 63 Patrick Droz for their comments and suggestions on the protocol. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 68 1.1 Sections of this document . . . . . . . . . . . . . . . . 5 69 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 6 70 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 3.1 Protocol Framework . . . . . . . . . . . . . . . . . . . . 9 72 3.1.1 The PL layer . . . . . . . . . . . . . . . . . . . . . 11 73 3.1.2 The TML layer . . . . . . . . . . . . . . . . . . . . 12 74 3.1.3 The FEM/CEM Interface . . . . . . . . . . . . . . . . 12 75 3.2 ForCES Protocol Phases . . . . . . . . . . . . . . . . . . 13 76 3.2.1 Pre-association . . . . . . . . . . . . . . . . . . . 13 77 3.2.2 Post-association . . . . . . . . . . . . . . . . . . . 14 78 3.3 Protocol Mechanisms . . . . . . . . . . . . . . . . . . . 15 79 3.3.1 Of Transactions, Atomicity and 2 Phase Commits . . . . 15 80 3.3.2 FE Protocol Object . . . . . . . . . . . . . . . . . . 15 81 3.3.3 Scaling by Concurrency . . . . . . . . . . . . . . . . 16 82 4. TML Requirements . . . . . . . . . . . . . . . . . . . . . . . 18 83 4.1 TML Parameterization . . . . . . . . . . . . . . . . . . . 19 84 5. Common Header . . . . . . . . . . . . . . . . . . . . . . . . 20 85 6. Protocol Messages . . . . . . . . . . . . . . . . . . . . . . 23 86 6.1 Association Messages . . . . . . . . . . . . . . . . . . . 23 87 6.1.1 Association Setup Message . . . . . . . . . . . . . . 23 88 6.1.2 Association Setup Response Message . . . . . . . . . . 24 89 6.1.3 Association Teardown Message . . . . . . . . . . . . . 25 90 6.2 Query and Response Messages . . . . . . . . . . . . . . . 25 91 6.2.1 Query Message . . . . . . . . . . . . . . . . . . . . 26 92 6.2.2 Query Response Message . . . . . . . . . . . . . . . . 29 93 6.3 Configuration Messages . . . . . . . . . . . . . . . . . . 31 94 6.3.1 Config Message . . . . . . . . . . . . . . . . . . . . 31 95 6.3.2 Config Response Message . . . . . . . . . . . . . . . 33 96 6.4 Event Notification and Response Messages . . . . . . . . . 34 97 6.4.1 Event Notification Message . . . . . . . . . . . . . . 35 98 6.4.2 Event Notification Response Message . . . . . . . . . 37 99 6.5 Packet Redirect Message . . . . . . . . . . . . . . . . . 38 100 6.6 State Maintenance Messages . . . . . . . . . . . . . . . . 42 101 6.6.1 State Maintenance Message . . . . . . . . . . . . . . 42 102 6.6.2 State Maintenance Response Message . . . . . . . . . . 43 103 6.7 Heartbeat Message . . . . . . . . . . . . . . . . . . . . 44 104 7. Protocol Scenarios . . . . . . . . . . . . . . . . . . . . . . 45 105 7.1 Association Setup state . . . . . . . . . . . . . . . . . 45 106 7.2 Association Established state or Steady State . . . . . . 46 107 8. High Availability Support . . . . . . . . . . . . . . . . . . 49 108 8.1 Responsibilities for HA . . . . . . . . . . . . . . . . . 51 109 9. Security Considerations . . . . . . . . . . . . . . . . . . . 52 110 9.1 No Security . . . . . . . . . . . . . . . . . . . . . . . 52 111 9.1.1 Endpoint Authentication . . . . . . . . . . . . . . . 52 112 9.1.2 Message authentication . . . . . . . . . . . . . . . . 53 114 9.2 ForCES PL and TML security service . . . . . . . . . . . . 53 115 9.2.1 Endpoint authentication service . . . . . . . . . . . 53 116 9.2.2 Message authentication service . . . . . . . . . . . . 53 117 9.2.3 Confidentiality service . . . . . . . . . . . . . . . 54 118 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 55 119 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 55 120 10.1 Normative References . . . . . . . . . . . . . . . . . . . . 55 121 10.2 Informational References . . . . . . . . . . . . . . . . . . 55 122 A. Individual Authors/Editors Contact . . . . . . . . . . . . . . 56 123 B. IANA considerations . . . . . . . . . . . . . . . . . . . . . 57 124 C. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 58 125 C.1 TML considerations . . . . . . . . . . . . . . . . . . . . 58 126 C.1.1 PL Flag inference by TML . . . . . . . . . . . . . . . 58 127 C.1.2 Message type inference to Mapping at the TML . . . . . 59 128 Intellectual Property and Copyright Statements . . . . . . . . 60 130 1. Introduction 132 This specification provides a draft definition of an IP-based 133 protocol for Control Element control of an Forwarding Element. The 134 protocol is a TLV based protocol that include commands for transport 135 of LFB information as well as TLVs for association, configuration, 136 status, and events. 138 This specification does not specify a transport mechanism for 139 messages, but does include a discussion of the services that must be 140 provided by the transport interface. 142 1.1 Sections of this document 144 Section 2 provides a glossary of terminology used in the 145 specification. 147 Section 3 provides an overview of the protocol including a discussion 148 on the protocol framework, descriptions of the protocol layer (PL) 149 and a transport mapping layer (TML), as well as of the ForCES 150 protocol mechanisms. 152 While this document does not define the TML, Section 4 details the 153 services that the TML must provide. 155 The Forces protocol is defined to have a common header for all other 156 message types. The header is defined in Section 5, while the 157 protocol messages are defined in Section 6. 159 Section 7 describes several Protocol Scenarios and includes message 160 exchange descriptions. 162 Section 8 describes mechanism in the protocol to support high 163 availability mechanisms including redundancy and fail over. Section 164 9 defines the security mechanisms provided by the PL and TML. 166 2. Definitions 168 This document follows the terminologies defined by the ForCES 169 Requirements in [RFC3654] and by the ForCES framework in [RFC3746]. 170 This document also uses the terminologies defined by ForCES FE model 171 in [FE-MODEL]. We copy the definitions of some terminologies as 172 below: 174 Addressable Entity (AE) - A physical device that is directly 175 addressable given some interconnect technology. For example, on IP 176 networks, it is a device to which we can communicate using an IP 177 address; and on a switch fabric, it is a device to which we can 178 communicate using a switch fabric port number. 180 Forwarding Element (FE) - A logical entity that implements the ForCES 181 protocol. FEs use the underlying hardware to provide per-packet 182 processing and handling as directed/controlled by a CE via the ForCES 183 protocol. 185 Control Element (CE) - A logical entity that implements the ForCES 186 protocol and uses it to instruct one or more FEs how to process 187 packets. CEs handle functionality such as the execution of control 188 and signaling protocols. 190 Pre-association Phase - The period of time during which a FE Manager 191 (see below) and a CE Manager (see below) are determining which FE and 192 CE should be part of the same network element. 194 Post-association Phase - The period of time during which a FE does 195 know which CE is to control it and vice versa, including the time 196 during which the CE and FE are establishing communication with one 197 another. 199 FE Model - A model that describes the logical processing functions 200 of a FE. 202 FE Manager (FEM) - A logical entity that operates in the 203 pre-association phase and is responsible for determining to which 204 CE(s) a FE should communicate. This process is called CE discovery 205 and may involve the FE manager learning the capabilities of available 206 CEs. A FE manager may use anything from a static configuration to a 207 pre-association phase protocol (see below) to determine which CE(s) 208 to use. Being a logical entity, a FE manager might be physically 209 combined with any of the other logical entities such as FEs. 211 CE Manager (CEM) - A logical entity that operates in the 212 pre-association phase and is responsible for determining to which 213 FE(s) a CE should communicate. This process is called FE discovery 214 and may involve the CE manager learning the capabilities of available 215 FEs. A CE manager may use anything from a static configuration to a 216 pre-association phase protocol (see below) to determine which FE to 217 use. Being a logical entity, a CE manager might be physically 218 combined with any of the other logical entities such as CEs. 220 ForCES Network Element (NE) - An entity composed of one or more CEs 221 and one or more FEs. To entities outside a NE, the NE represents a 222 single point of management. Similarly, a NE usually hides its 223 internal organization from external entities. 225 High Touch Capability - This term will be used to apply to the 226 capabilities found in some forwarders to take action on the contents 227 or headers of a packet based on content other than what is found in 228 the IP header. Examples of these capabilities include NAT-PT, 229 firewall, and L7 content recognition. 231 Datapath -- A conceptual path taken by packets within the forwarding 232 plane inside an FE. 234 LFB (Logical Function Block) type -- A template representing a 235 fine-grained, logically separable and well-defined packet processing 236 operation in the datapath. LFB types are the basic building blocks 237 of the FE model. 239 LFB (Logical Function Block) Instance -- As a packet flows through an 240 FE along a datapath, it flows through one or multiple LFB instances, 241 with each implementing an instance of a certain LFB type. There may 242 be multiple instances of the same LFB in an FE's datapath. Note that 243 we often refer to LFBs without distinguishing between LFB type and 244 LFB instance when we believe the implied reference is obvious for the 245 given context. 247 LFB Metadata -- Metadata is used to communicate per-packet state from 248 one LFB to another, but is not sent across the network. The FE model 249 defines how such metadata is identified, produced and consumed by the 250 LFBs, but not how metadata is encoded within an implementation. 252 LFB Attribute -- Operational parameters of the LFBs that must be 253 visible to the CEs are conceptualized in the FE model as the LFB 254 attributes. The LFB attributes include, for example, flags, single 255 parameter arguments, complex arguments, and tables that the CE can 256 read or/and write via the ForCES protocol (see below). 258 LFB Topology -- Representation of how the LFB instances are logically 259 interconnected and placed along the datapath within one FE. 260 Sometimes it is also called intra-FE topology, to be distinguished 261 from inter-FE topology. 263 FE Topology -- A representation of how the multiple FEs within a 264 single NE are interconnected. Sometimes this is called inter-FE 265 topology, to be distinguished from intra-FE topology (i.e., LFB 266 topology). 268 Inter-FE Topology -- See FE Topology. 270 Intra-FE Topology -- See LFB Topology. 272 Following terminologies are defined by this document: 274 ForCES Protocol - While there may be multiple protocols used within 275 the overall ForCES architecture, the term "ForCES protocol" refers 276 only to the protocol used at the Fp reference point in the ForCES 277 Framework in RFC3746 [RFC3746]. This protocol does not apply to 278 CE-to-CE communication, FE-to-FE communication, or to communication 279 between FE and CE managers. Basically, the ForCES protocol works in 280 a master-slave mode in which FEs are slaves and CEs are masters. 281 This document defines the specifications for this ForCES protocol. 283 ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol 284 architecture that defines the ForCES protocol messages, the protocol 285 state transfer scheme, as well as the ForCES protocol architecture 286 itself (including requirements of ForCES TML (see below)). 287 Specifications of ForCES PL are defined by this document. 289 ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in 290 ForCES protocol architecture that specifically addresses the protocol 291 message transportation issues, such as how the protocol messages are 292 mapped to different transport media (like TCP, IP, ATM, Ethernet, 293 etc), and how to achieve and implement reliability, multicast, 294 ordering, etc. The ForCES TML is specifically addressed in a 295 separate ForCES TML Specification document. 297 3. Overview 299 The reader is referred to the Framework document [RFC3746], and in 300 particular sections 3 and 4, for architectural overview and where and 301 how the ForCES protocol fits in. There may be some content overlap 302 between the framework document and this section in order to provide 303 clarity. 305 3.1 Protocol Framework 307 Figure 1 below is reproduced from the Framework document for clarity. 308 It shows a NE with two CEs and two FEs. 310 --------------------------------------- 311 | ForCES Network Element | 312 -------------- Fc | -------------- -------------- | 313 | CE Manager |---------+-| CE 1 |------| CE 2 | | 314 -------------- | | | Fr | | | 315 | | -------------- -------------- | 316 | Fl | | | Fp / | 317 | | Fp| |----------| / | 318 | | | |/ | 319 | | | | | 320 | | | Fp /|----| | 321 | | | /--------/ | | 322 -------------- Ff | -------------- -------------- | 323 | FE Manager |---------+-| FE 1 | Fi | FE 2 | | 324 -------------- | | |------| | | 325 | -------------- -------------- | 326 | | | | | | | | | | 327 ----+--+--+--+----------+--+--+--+----- 328 | | | | | | | | 329 | | | | | | | | 330 Fi/f Fi/f 332 Fp: CE-FE interface 333 Fi: FE-FE interface 334 Fr: CE-CE interface 335 Fc: Interface between the CE Manager and a CE 336 Ff: Interface between the FE Manager and an FE 337 Fl: Interface between the CE Manager and the FE Manager 338 Fi/f: FE external interface 340 Figure 1: ForCES Architectural Diagram 342 The ForCES protocol domain is found in the Fp Reference Point. The 343 Protocol Element configuration reference points, Fc and Ff also play 344 a role in the booting up of the Forces Protocol. The protocol 345 element configuration is out of scope of the ForCES protocol but is 346 touched on in this document since it is an integral part of the 347 protocol pre-association phase. 349 Figure 2 below shows further breakdown of the Fp interface by example 350 of a MPLS QoS enabled Network Element. 352 ------------------------------------------------- 353 | | | | | | | 354 |OSPF |RIP |BGP |RSVP |LDP |. . . | 355 | | | | | | | 356 ------------------------------------------------- 357 | ForCES Interface | 358 ------------------------------------------------- 359 ^ ^ 360 | | 361 ForCES | |data 362 control | |packets 363 messages| |(e.g., routing packets) 364 | | 365 v v 366 ------------------------------------------------- 367 | ForCES Interface | 368 ------------------------------------------------- 369 | | | | | | | 370 |LPM Fwd|Meter |Shaper |MPLS |Classi-|. . . | 371 | | | | |fier | | 372 ------------------------------------------------- 374 Figure 2: Examples of CE and FE functions 376 The ForCES Interface shown in Figure B constitutes two pieces: the PL 377 and TML layer. 379 This is depicted in Figure 3 below. 381 +------------------------------------------------ 382 | CE PL layer | 383 +------------------------------------------------ 384 | CE TML layer | 385 +------------------------------------------------ 386 ^ 387 | 388 ForCES | (i.e Forces data + control 389 PL | packets ) 390 messages | 391 over | 392 specific | 393 TML | 394 encaps | 395 and | 396 transport | 397 | 398 v 399 +------------------------------------------------ 400 | FE TML layer | 401 +------------------------------------------------ 402 | FE PL layer | 403 +------------------------------------------------ 405 Figure 3: ForCES Interface 407 The PL layer is in fact the ForCES protocol. Its semantics and 408 message layout are defined in this document. The TML Layer is 409 necessary to connect two ForCES PL layers as shown in Figure 3 above. 410 The TML is out of scope for this document but is within scope of 411 ForCES. This document defines requirements the PL needs the TML to 412 meet. 414 Both the PL and TML layers are standardized by the IETF. While only 415 one PL layer is defined, different TMLs are expected to be 416 standardized. To interoperate the TML layer at the CE and FE are 417 expected to be of the same definition. 419 On transmit, the PL layer delivers its messages to the TML layer. 420 The TML layer delivers the message to the destination TML layer(s). 421 On receive, the TML delivers the message to its destination PL 422 layer(s). 424 3.1.1 The PL layer 426 The PL is common to all implementations of ForCES and is standardized 427 by the IETF as defined in this document. The PL layer is responsible 428 for associating an FE or CE to an NE. It is also responsible for 429 tearing down such associations. An FE uses the PL layer to throw 430 various subscribed-to events to the CE PL layer as well as respond to 431 various status requests issued from the CE PL. The CE configures 432 both the FE and associated LFBs attributes using the PL layer. In 433 addition the CE may send various requests to the FE to activate or 434 deactivate it, reconfigure its HA parametrization, subscribe to 435 specific events etc. More details in section Section 6. 437 3.1.2 The TML layer 439 The TML layer is essentially responsible for transport of the PL 440 layer messages. The TML is where the issues of how to achieve 441 transport level reliability, congestion control, multicast, ordering, 442 etc are handled. It is expected more than one TML will be 443 standardized. The different TMLs each could implement things 444 differently based on capabilities of underlying media and transport. 445 However, since each TML is standardized, interoperability is 446 guaranteed as long as both endpoints support the same TML. All 447 ForCES Protocol Layer implementations should be portable across all 448 TMLs, because all TMLs have the same top edge semantics as defined in 449 this document. 451 3.1.3 The FEM/CEM Interface 453 The FEM and CEM components, although valuable in the setup and 454 configurations of both the PL and TML layers, are out of scope of the 455 ForCES protocol. The best way to think of them are as 456 configurations/parameterizations for the PL and TML before they 457 become active (or even at runtime based on implementation). In the 458 simplest case, the FE or CE read a static configuration file which 459 they use as the FEM/CEM interface. RFC 3746 has a lot more detailed 460 descriptions on how the FEM and CEM could be used. We discuss the 461 pre-association phase where the CEM and FEM play briefly in section 462 Section 3.2.1. 464 An example of typical things FEM/CEM would configure would be TML 465 specific parameterizations such as: 466 a. how the TML connection should happen (example what IP addresses 467 to use, transport modes etc); 468 b. the ID for the FE or CE would also be issued at this point. 469 c. Security parameterization such as keys etc. 470 d. Connection association parameters 472 Example "send up to 3 association messages each 1 second apart" Vs " 473 send up to 4 association messages with increasing exponential 474 timeout". 476 3.2 ForCES Protocol Phases 478 ForCES in relation to NEs involves two phases: the Pre-Association 479 phase where configuration/initialization/bootup of the TML and PL 480 layer happens, and the association phase where the ForCES protocol 481 operates. 483 3.2.1 Pre-association 485 The ForCES interface is configured during the Pre association phase. 486 In a simple setup, the configuration is static and is read from some 487 saved config file. All the parameters for the association phase are 488 well known after the pre association phase is complete. A protocol 489 such as DHCP may be used to retrieve the config parameters instead of 490 reading from a static config file. Note this will still be 491 considered static pre-association. Dynamic configuration may also 492 happen in the Fc, Ff and Fl reference points. Vendors may use their 493 own proprietary service discovery protocol to pass the parameters. 495 We reproduce some scenarios from the Framework Document to show a 496 pre-association example. 498 <----Ff ref pt---> <--Fc ref pt-------> 499 FE Manager FE CE Manager CE 500 | | | | 501 | | | | 502 (security exchange) (security exchange) 503 1|<------------>| authentication 1|<----------->|authentication 504 | | | | 505 (FE ID, attributes) (CE ID, attributes) 506 2|<-------------| request 2|<------------|request 507 | | | | 508 3|------------->| response 3|------------>|response 509 (corresponding CE ID) (corresponding FE ID) 510 | | | | 511 | | | | 513 Figure 4: Examples of a message exchange over the Ff and Fc reference 514 points 516 <-----------Fl ref pt--------------> | 518 FE Manager FE CE Manager CE 519 | | | | 520 | | | | 521 (security exchange) | | 522 1|<------------------------------>| | 523 | | | | 524 (a list of CEs and their attributes) | 525 2|<-------------------------------| | 526 | | | | 527 (a list of FEs and their attributes) | 528 3|------------------------------->| | 529 | | | | 530 | | | | 532 Figure 5: An example of a message exchange over the Fl reference 533 point 535 Before the transition to the association phase, the FEM will have 536 established contact with the appropriate CEM component. 537 Initialization of the ForCES interface will be completed, and 538 Authentication and capabilities discovery may be complete as well. 539 Both the FE and CE would know how to connect to each other for 540 configuration, accounting, identification and authentication 541 purposes. Both sides are also knowledgeable of all necessary 542 protocol parameters such as timers, etc. The Fl reference point may 543 continue to operate during the association phase and may be used to 544 force a disassociation of an FE or CE. Because the Pre-association 545 phase is out of scope, we do not discuss these details any further. 546 The reader is referred to the framework document for more detailed 547 discussion. 549 3.2.2 Post-association 551 In this phase, the FE and CE components talk to each other using the 552 ForCES protocol (PL over TML) as defined in this document. There are 553 three sub-phases: Association setup state, Established State, and 554 Association teardown state. 556 3.2.2.1 Association setup state 558 The FE attempts to join the NE. The FE may be rejected or accepted. 559 Once granted access into the NE, capabilities exchange happen with 560 the CE querying the FE. Armed with the FE capability knowledge, the 561 CE can offer an initial configure (possibly to restore state) and 562 query certain attributes within either an LFB or the FE itself. 564 A lot more details are provided in the protocol scenarios section. 566 On successful completion of this state, the FE joins the NE and is 567 moved to the Established State. 569 3.2.2.2 Association Established state 571 In this state the FE is continuously updated or queried. The FE may 572 also send asynchronous event notifications to the CE or synchronous 573 heartbeat notifications. This continues until a termination is 574 initiated by either the CE or FE. 576 Refer to section on protocol scenarios for more details. 578 3.3 Protocol Mechanisms 580 Various semantics are exposed to the protocol users via the PL header 581 including: Transaction capabilities, atomicity of transactions, two 582 phase commits, batching/parallelization, High Availability and 583 failover as well as command windows. 585 3.3.1 Of Transactions, Atomicity and 2 Phase Commits 587 A transaction is a sequence of operations that is guaranteed to be 588 atomic in the presence of any failures by the CEs or FEs. Operation 589 in this sense implies the PL operation within the message body TLV. 590 An example of a transaction could be a config PL msg with a sequence 591 of operations: "route-add A B,C:route-del X" (each operation in its 592 own TLV). 594 If a transaction is split across more than one message, then all 595 message batch must arrive at the destination before they are executed 596 on either the LFB or FE. All operations are executed serially in the 597 order specified by the transaction. If any of the sequence of 598 operations in a transaction fails then the transaction is declared as 599 a failure. This is an all-or-nothing approach and is needed to 600 ensure consistency of a transaction across multiple FEs. 602 A transaction may be atomic within an FE alone or across the NE. In 603 both cases the atomic requirement for a transaction MUST be met. The 604 PL message header exposes ability to mark a start of transaction and 605 end of transaction using flags. These flags can be used to derive a 606 classical transactional two phase commit[ACID paper ref here]. 608 3.3.2 FE Protocol Object 610 The FE Protocol Object is a logical entity in each FE that is used to 611 control the ForCES protocol. It is defined in the same fashion as 612 LFBs. The FE Protocol Object can be manipulated using the standard 613 Config/Query messages. The FE Protocol Object Type ID is assigned 614 the value 0x1. The FE Protocol Instance ID is assigned the value 615 0x1. There must always be one and only one instance of the FE 616 Protocol Object in an FE. The values of the attributes in the FE 617 Protocol Object have pre-defined default values that are specified 618 here. Unless explicit changes are made to these values using Config 619 messages from the CE, these default values MUST be used for the 620 operation of the protocol. 622 The FE Protocol Object consists of the following elements: 623 FE Protocol events that can be subscribed/unsubscribed: 624 FE heartbeat 625 FE TML events (TBD) 626 FE Protocol capabilities: 627 Supported ForCES protocol version(s) by the FE 628 Supported ForCES FE model(s) by the FE 629 Some TML capability description(s) 630 FE Protocol attributes: 631 current version of the ForCES protocol 632 current version of the FE model 633 Association Expiry Timer 634 Heartbeat Interval 635 Primary CE 636 FE failover and restart policy 638 The FE Object (referred to as "FE attributes" in the model draft) 639 should not be confused with the FE Protocol Object. The FE Object 640 contains attributes relative to the FE itself, and not to the 641 operation of the ForCES protocol between the CE and the FE. Such 642 attributes can be FEState (refer to model draft), vendor, etc. The 643 FE Object Type ID is assigned the value 0x2. The FE Protocol 644 Instance ID is assigned the value 0x1. There must always be one and 645 only one instance of the FE Object in an FE. 647 The FE Object consists of the following elements 648 FE Events: 649 FEStatusChange (FE Up/Down/Active/Inactive/Failover) 650 FE DoS alert 651 FE capability change 652 FE attributes: 653 FE Behavior Exp. Timer 654 HA Mode 656 3.3.3 Scaling by Concurrency 658 It is desirable that the PL layer is not the bottleneck when larger 659 bandwidth pipes become available. To pick a mythical example in 660 todays terms, if a 100Gbps pipe was made available and there is 661 sufficient work then the PL layer should take advantage and use all 662 of the 100Gbps pipe. Two semantics are allowed to achieve this. The 663 first one is batching and the second one is a command window. 664 Batching is ability to send multiple commands (such as config) in one 665 PDU. The size of the batch will be affected by amongst other things 666 the path MTU. The commands may be part of the same transaction or 667 unrelated transactions which are independent of each other. Command 668 windowing allows for pipelining of independent transactions which do 669 not affect each other. Each independent transaction could be one or 670 more batches. 672 3.3.3.1 Batching 674 TBD 676 3.3.3.2 Command Pipelining 678 TBD 680 4. TML Requirements 682 The requirements below are expected to be delivered by the TML. This 683 text does not define how such mechanisms are delivered. As an 684 example they could be defined to be delivered via hardware or 685 inter-TML protocol level schemes. 687 Each TML must describe how it contributes to achieving the listed 688 ForCES requirements. If for any reason a TML does not provide a 689 service listed below a justification needs to be provided. 690 1. Reliability 691 As defined by RFC 3654, section 6 #6. 692 2. Security 693 TML provides security services to the ForCES PL. TML layer 694 should support following security services and describe how they 695 are achieved. 696 * Endpoint authentication of FE and CE. 697 * Message Authentication 698 * Confidentiality service 699 3. Congestion Control 700 The congestion control scheme used needs to be defined. 701 Additionally, under what circumstances is notification sent to 702 the PL to notify it of congestion. 703 4. Uni/multi/broadcast addressing/delivery if any 704 If theres any mapping between PL and TML level Uni/Multi/ 705 Broadcast addressing it needs to be defined. 706 5. Timeliness 708 Editorial Note: Does the TML allow for obsoleting msgs? If yes, 709 it needs to say how. 710 6. HA decisions 711 It is expected that availability of transport links is the TMLs 712 responsibility. However, on config basis, the PL layer may wish 713 to participate in link failover schemes and therefore the TML 714 must provide this capability. 715 Please refer to the HA Section Section 8 for details. 716 7. Encapsulations used. 717 Different types of TMLs will encapsulate the PL messages on 718 different types of headers. The TML needs to specify the 719 encapsulation used. 720 8. Prioritization 721 It is expected that the TML will be able to handle up to 8 722 priority levels needed by the PL layer and will provide 723 preferential treatment. 724 TML needs to define how this is achieved. 726 4.1 TML Parameterization 728 It is expected that it should be possible to use a configuration 729 reference point, such as the FEM or the CEM, to configure the TML. 731 Some of the parameters may include: 732 o PL ID 733 o Connection Type and associated data. For example if a TML uses 734 IP/TCP/UDP then parameters such as TCP and UDP ports, IP addresses 735 need to be configured. 736 o number of transport connections 737 o Connection Capability, such as bandwidth, etc. 738 o Allowed/Supported Connection QoS policy (or Congestion Control 739 Policy) 741 5. Common Header 743 0 1 2 3 744 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 745 0 1 2 3 746 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 747 |version| rsvd | Message Type | Length | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 749 | Source ID | 750 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 751 | Destination ID | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 | Sequence Number | 754 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 755 | flags | 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 758 Figure 6: Common Header 760 The message is 32 bit aligned. 761 Version (4 bit): 762 Version with a 2 bit major and 2 bit minor. 763 rsvd (4 bit): 764 Unused at this point. A receiver should not interpret this 765 field. 766 Command (8 bits): 767 Commands are defined in Section 6. 768 Source ID (32 bit): 769 Dest ID (32 bit): 770 * Above are 32 bit IDs which recognize the termination point. 771 Ideas discussed so far are desire to recognize if ID belongs 772 to FE or CE by inspection. Suggestions for achieving this 773 involves partitioning of the ID allocation. Another 774 alternative maybe to use flags to indicate direction (this 775 avoids partition). 776 * IDs will allow multi/broad/unicast 777 * Addressing 778 a. As ForCES may run between multiple CEs and FEs and over 779 different protocols such as IPv4 and IPv6, or directly 780 over Ethernet or other switching-fabric interconnects, it 781 is necessary to create an addressing scheme for ForCES 782 entities. Mappings to the underlying TML-level 783 addressing can then be defined as appropriate. 784 b. Fundamentally, unique IDs are assigned to CEs and FEs. A 785 split address space is used to distinguish FEs from CEs. 786 Even though we can assume that in a large NE there are 787 typically two or more orders of magnitude more FEs than 788 CEs, the address space is split uniformly for simplicity. 790 c. Special IDs are reserved for FE broadcast, CE broadcast, 791 and NE broadcast. 792 d. Subgroups of FEs belonging, for instance, to the same 793 VPN, may be assigned a multicast ID. Likewise, subgroups 794 of CEs that act, for instance, in a back-up mode may be 795 assigned a multicast ID. These FEs and CE multicast IDs 796 are chosen in a distinct portion of the ID address space. 797 Such a multicast ID may comprise FEs, CEs, or a mix of 798 both. 799 e. As a result, the address space allows up to 2^30 (over a 800 billion) CEs and the same amount of FEs. 802 0 1 2 3 803 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 804 0 1 2 3 805 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 806 |TS | sub-ID | 807 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 809 Figure 7: ForCES ID Format 811 f. The ForCES ID is 32 bits. The 2 most significant bits 812 called Type Switch (TS) are used to split the ID space as 813 follows: 814 A. TS Corresponding ID range Assignment 815 B. -- ---------------------- ---------- 816 C. 0b00 0x00000000 to 0x3FFFFFFF FE IDs (2^30) 817 D. 0b01 0x40000000 to 0x7FFFFFFF CE IDs (2^30) 818 E. 0b10 0x80000000 to 0xBFFFFFFF reserved 819 F. 0b11 0xC0000000 to 0xFFFFFFEF multicast IDs 820 (2^30 - 16) 821 G. 0b11 0xFFFFFFF0 to 0xFFFFFFFC reserved 822 H. 0b11 0xFFFFFFFD all CEs broadcast 823 I. 0b11 0xFFFFFFFE all FEs broadcast 824 J. 0b11 0xFFFFFFFF all FEs and CEs 825 (NE) broadcast 826 g. It is desirable to address multicast and/or broadcast 827 messages to some LFB instances of a given class. For 828 instance, assume FEs FEa and FEb: 829 - FEa has LFBs LFBaX1 and LFBaX2 of class X 830 - similarly, FEb has two LFBs LFBbX1 and LFBbX2 of 831 class X. 832 A broadcast message should be addressable to only LFBs 833 LFBaX1 and LFBbX1 (this can be the case for instance if 834 these two LFBs belong to the same VPN). To achieve this, 835 a VPN ID (3 octets OUI and 4 octets VPN Index) as defined 836 in RFC 2685 should be used within the ForCES message body 837 as a TLV. 839 As an alternative, a particular multicast ID MAY be 840 associated to a given VPN ID through some configuration 841 means. Messages delivered to such a multicast ID MUST 842 only be applied to LFBs belonging to that VPN ID. 844 Sequence (32 bits) 845 Unique to a PDU. [Discussion: There may be impact on the effect 846 of subsequence numbers]. 847 length (16 bits): 848 length of header + the rest of the message in DWORDS (4 byte 849 increments). 850 Flags(32 bits): 851 Identified so far: 852 * ACK indicator(2 bit) 853 The description for using the two bits is: 854 'NoACK' (00) | 'SuccessACK'(01) | 'UnsuccessACK'(10) | 855 'ACKAll' (11) 856 * 857 unknown/undecided. 858 * Throttle flag? 859 * batch (2 bits) 860 * Atomicity (1 or 2 bits) 862 Editorial Note: There are several open issues, listed below, in the 863 header which still need to be settled: 865 1. Parallelization of PL Windowing/subsequence 866 Someone to look into ISCSI 867 2. events and replies and relation to peer to peer 868 vs master slave 869 3. We need to discuss whether some of the Flags 870 such as those for Atomicity, Batching are needed 871 in the common header or only belong to the 872 Config message. 874 6. Protocol Messages 876 6.1 Association Messages 878 The ForCES Association messages are used to establish and teardown 879 associations between FEs and CEs. 881 6.1.1 Association Setup Message 883 This message is sent by the FE to the CE to setup a ForCES 884 association between them. This message could also be used by CEs to 885 join a ForCES NE, however CE-to-CE communication is not covered by 886 this protocol. 888 Message transfer direction: 889 FE to CE 890 Message Header: 891 The Message Type in the header is set MessageType= 'Association 892 Setup'. The ACK flag in the header is ignored, because the setup 893 message will always expect to get a response from the message 894 receiver (CE) whether the setup is successful or not. The Src ID 895 (FE ID) may be set to O in the header which means that the FE 896 would like the CE to assign a FE ID for the FE in the setup 897 response message. 898 Message body: 899 The setup message body consists of one optional TLV, the format of 900 which is as follows: 902 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 903 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 904 | Type = HBI | Length | 905 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 906 | Heartbeat Interval | 907 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 Figure 8 911 Type (16 bits): 912 Currently only one Type defined, HBI-heart beat interval. 913 Length (16 bits): 914 Length of the TLV including the T and L fields, in bytes. 915 Heartbeat Interval (32 bits): 916 This indicates the current HB interval on the FE in milliseconds. 917 A default value for this will be defined. 919 Editorial Note: Whether HBI belongs to the setup is still under 920 discussion. 921 Editorial Note: In certain situations (such as use of multicast 922 IDs), it might not be possible to make use of the 923 procedure described above for the FE to 924 dynamically obtain an ID from the CE. Such 925 situations need to be identified. 927 6.1.2 Association Setup Response Message 929 This message is sent by the CE to the FE in response to the Setup 930 message. It indicates to the FE whether the setup is successful or 931 not, i.e. whether an association is established. 933 Message transfer direction: 934 CE to FE 935 Message Header: 936 The Message Type in the header is set MessageType= 'Setup 937 Response'. The ACK flag in the header is always ignored, because 938 the setup response message will never expect to get any more 939 response from the message receiver (FE). The Dst ID in the 940 header will be set to some FE ID value assigned by the CE if the 941 FE had requested that in the setup message (by SrcID = 0). 942 Message body: 943 The setup response message body consists of one TLV, the format 944 of which is as follows: 946 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 947 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 948 | Type = Result | Length | 949 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 950 | Result | Reserved | 951 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 953 Figure 9 955 Type (16 bits): 956 Currently only one Type i.e. Setup Result is required. Other 957 TLVs are optional. 958 Length (16 bits): 959 Length of the TLV including the T and L fields, in bytes. 960 Result (16 bits): 961 This indicates whether the setup msg was successful or whether 962 the FE request was rejected by the CE. 964 6.1.3 Association Teardown Message 966 This message can be sent by the FE or CE to any ForCES element to end 967 its ForCES association with that element. 969 Message transfer direction: 970 CE to FE, or FE to CE (or CE to CE) 971 Message Header: 972 The Message Type in the header is set MessageType= "Asso. 973 Teardown"(TBD?). The ACK flag in the header is always ignored, 974 because the teardown message will never expect to get any 975 response from the message receiver. 976 Message body: 977 The association teardown message body consists of one TLV, the 978 format of which is as follows: 980 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 981 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 982 | Type = T.reason | Length | 983 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 984 | Reason (optional) | 985 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 987 Figure 10 989 Type (16 bits): 990 Currently only one Type defined - Teardown Reason. 991 Length (16 bits): 992 Length of the TLV including the T and L fields, in bytes. 993 T.reason (32 bits): 994 This indicates the reason why the association is being 995 terminated. 997 6.2 Query and Response Messages 999 Editorial Note: If the approach of using an FE Protocol & FE Object 1000 is fully adopted and no other reason for having FE 1001 TLVs is identified, then no distinction will be 1002 further made in the TLV types between FE* and LFB*. 1003 As a result, the Type ID and Instance ID in the TLV 1004 will also be used to identify the FE Protocol 1005 Object, with specific values as mentioned in Section 1006 3.3.2 1008 The ForCES query and response messages are used for one ForCES 1009 element (CE or FE) to query other ForCES element(s) for various kinds 1010 of information. Current version of ForCES protocol limits the use of 1011 the messages only for CE to query information of FE. The information 1012 to be queried in FE can be categorized into two types: 1014 1) FE (coarse layer) information 1016 This type of information is about the property of an FE, taking the 1017 FE as a whole, e.g., the total available memory space in the FE. To 1018 query this type of information, we should take the whole FE as the 1019 addressing destination. Information of this type includes: 1021 o Inter-FE topology 1022 o Intra-FE topology, that is, LFB topology 1023 o FE capabilities 1024 o FE attributes 1025 o FE statistics 1027 Another way to recognize FE coarse layer property is to define two 1028 objects, the 'FE Protocol Object' and the 'FE Object' at this coarse 1029 layer. See Section 3.3.2 for more details. 1031 2) LFB information 1033 This type of information is about property of an LFB inside an FE, 1034 e.g., routing rules of a Forwarder LFB in an FE. To query this type 1035 of information, we should take the LFB as the addressing destination. 1036 Information of this type include: 1038 o LFB capabilities 1039 o LFB attributes 1040 o LFB statistics 1042 6.2.1 Query Message 1044 As usual, a query message is composed of a common header and a 1045 message body that consists of one or more TLV data format. Detailed 1046 description of the message is as below. 1048 Message transfer direction: 1049 Current version limits the query message transfer direction only 1050 from CE to FE. 1051 Message Header: 1052 The Message Type in the header is set to MessageType= 'Query'. 1053 The ACK flag in the header SHOULD be set 'ACKAll', meaning a full 1054 response for a query message is always expected. If the ACK flag 1055 is set other values, the meaning of the flag will then be 1056 ignored, and a full response will still be returned by message 1057 receiver. 1059 Message body: 1060 The query message body consists of (at least) one or more than 1061 one TLVs that describe entries to be queried. According to the 1062 queried information being FE (coarse layer) information or LFB 1063 information as described above, the message body TLV has 1064 different data format as below: 1066 To query FE (coarse layer) information, the message body TLV data 1067 format is: 1069 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1070 | Type='FEQuery' | Length | 1071 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1072 ~ Query Entry #1 ~ 1073 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1074 ~ Query Entry #2 ~ 1075 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1076 ~ ... ~ 1077 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 ~ Query Entry #N ~ 1079 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1081 To query LFB information, the message body TLV data format is: 1083 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1084 | Type='LFBQuery' | Length | 1085 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1086 | Type ID | Instance ID | 1087 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1088 ~ Query Entry #1 ~ 1089 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1090 ~ Query Entry #2 ~ 1091 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1092 ~ ... ~ 1093 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1094 ~ Query Entry #N ~ 1095 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1097 Figure 11 1099 Editorial Note: 1100 1. Under discussion is, when an 'FE Protocol 1101 Object' idea is adopted, above two kind of 1102 data formats may be mapped into one format, 1103 with the Type ID and Instance ID changed to 1104 Managed Object (MO) Type ID and MO Instance 1105 ID, and with two specific MO Type ID and 1106 Instance ID for 'FE Protocol Object' and 'FE 1107 Object', and others for 'FE LFB Object'. 1108 2. Under discussion is, do we need to support 1109 multiple objects addressing at the LFB Type 1110 and LFB Instance layer? One simple way to 1111 support multiple LFB types or instances is 1112 to use TLVs to identify the group of Type 1113 IDs and Instance IDs, rather than only one 1114 Type and Instance ID. A range of Instance 1115 IDs may also be supported in this way. 1117 Query Entry: 1118 This is a TLV that describes the entry to be queried, as follows: 1120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1121 | Type | Length | 1122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1123 ~ Description of the Query Entry ~ 1124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1126 Figure 12 1128 Type: 1129 [Under discussion and TBD] 1131 Editorial Note: There is a debate on how the Type here can be 1132 used. One possible use for the Type is to 1133 specify the encoding type for the TLV value. 1134 The possible encoding types are that like XML, 1135 binary ID based TLV coding, etc, therefore, the 1136 possible value for the Type may be 1137 'XMLEncoding', 'ID-BasedBinaryEncoding', etc. 1138 The Cons say that it may be impractical to 1139 directly use XML encoding in the protocol 1140 format, leaving no encoding type other than 1141 ID-based binary encoding to be specified, hence 1142 no need to specify encoding type. Another 1143 possible use of the Type is to number the 1144 entries, by which a more flexible response based 1145 on the number may become be achieved. 1147 Description of the Query Entry: 1148 This field presents the detailed description about the entry to 1149 be queried. The encoding of the description is based on the 1150 ForCES FE model if the entry is defined by FE model, or based on 1151 vendor specifications if the entry is defined by vendors. Note 1152 that the encoding is responsible for the 32 bits alignment of the 1153 description field. Usually, the description should include 1154 information about the name (or the name ID) of the entry to be 1155 queried. Occasionally, it may also include some more 1156 information, like some conditions that the queried entry is 1157 required to meet. For instance, consider a case in which a CE is 1158 going to query a Forwarder LFB in an FE for its current routing 1159 table information. In this case, CE may be interested in knowing 1160 (querying) all routing rules in the table, CE may also be 1161 interested in only knowing (querying) a few routing rules that 1162 meet some specific conditions, e.g., routing rules whose source 1163 IP address should match '210.33.X.X'. In the former case, only 1164 the name of the LFB attribute (as 'routing table') should be told 1165 in the query entry description, while in the latter case, the 1166 matching conditions should also be told in the description. 1167 Taking another policer LFB as one more example, the policer LFB 1168 may have attribute like the provisions (rules) for the policer, 1169 therefore, in the query entry TLV, we may set the queied entry 1170 name as the 'Provision'. To only set the name of the attribute 1171 as 'Provision' will dump all provision items in the LFB; while to 1172 set the attribute name and followed by some conditions will dump 1173 the provision items that meet the conditions. The index of the 1174 provision items can also be as the conditions, e.g., to set the 1175 conditions as 'the index of the provision items should range from 1176 11 to 15', then will return query result that only include the 1177 provision items ranging from 11 to 15. 1179 6.2.2 Query Response Message 1181 When receiving a query message, the receiver should process the 1182 message and come up with a query result. The receiver sends the 1183 query result by use of the Query Response Message back to the query 1184 message sender. The query result can be the information being 1185 queried if the query operation is successful, or can also be error 1186 codes if the query operation fails, indicating the reasons for the 1187 failure. 1189 A query response message is also composed of a common header and a 1190 message body consists of one or more TLVs describing the query 1191 result. Detailed description of the message is as below. 1193 Message transfer direction: 1194 Current version limits the query response message transfer 1195 direction only from FE to CE. 1196 Message Header: 1197 The Message Type in the header is set to MessageType= 1198 'QueryResponse'. The ACK flag in the header SHOULD be set 1199 'NoACK', meaning no further response for a query response message 1200 is expected. If the ACK flag is set other values, the meaning of 1201 the flag will then be ignored. The Sequence Number in the header 1202 SHOULD keep the same as that of the query message to be 1203 responded, so that the query message sender can keep track of the 1204 responses. 1205 Message body: 1206 The message body for a query response message consists of (at 1207 least) one or more than one TLVs that describe query results to 1208 individual queried entries. According to the queried information 1209 being FE (coarse layer) information or LFB information as 1210 described above, the response message body TLV has different data 1211 format as below: 1213 To respond to the query for FE (coarse layer) information, the 1214 response TLV has following data format: 1216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1217 | Type='FEQueryResponse' | Length | 1218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1219 ~ Response to Query Entry #1 ~ 1220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1221 ~ Response to Query Entry #2 ~ 1222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1223 ~ ... ~ 1224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1225 ~ Response to Query Entry #N ~ 1226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1228 Figure 13 1230 To respond to the query for LFB information, the response TLV has 1231 data format as: 1233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1234 | Type='LFBQueryResponse' | Length | 1235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1236 | Type ID | Instance ID | 1237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1238 ~ Response to Query Entry #1 ~ 1239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1240 ~ Response to Query Entry #2 ~ 1241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1242 ~ ... ~ 1243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1244 ~ Response to Query Entry #N ~ 1245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1247 Figure 14 1249 Response to Query Entry: 1250 This is a TLV that describes the response to the queried entry, 1251 as follows: 1253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1254 | Type | Length | 1255 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1256 ~ Description of Response to Query Entry ~ 1257 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1259 Figure 15 1261 Type: 1262 [Under discussion and TBD] 1263 Description of Response to Query Entry: 1264 This field presents the detailed description about the query 1265 result of an entry. The encoding of the description is based on 1266 the ForCES FE model if the entry is defined by FE model, or based 1267 on vendor specifications if the entry is defined by vendors. 1268 Note that the encoding is responsible for the 32 bits alignment 1269 of the description field. When the query is successful, the 1270 response result will include the information being queried. When 1271 the query is failed, the response result will usually include the 1272 information about the reason for the failure. 1274 6.3 Configuration Messages 1276 Editorial Note: If the approach of using an FE Protocol & FE Object 1277 is fully adopted and no other reason for having FE 1278 TLVs is identified, then no distinction will be 1279 further made in the TLV types between FE* and LFB*. 1280 As a result, the Type ID and Instance ID in the TLV 1281 will also be used to identify the FE Protocol 1282 Object, with specific values as mentioned in Section 1283 3.3.2 1285 The ForCES Configuration messages are used by the CEs to configure 1286 the FEs in a ForCES NE and report the results back to the CE. 1288 6.3.1 Config Message 1290 This message is sent by the CE to the FE to configure FE or LFB 1291 attributes. This message is also used by the CE to subscribe/ 1292 unsubscribe to FE, LFB events. 1294 Message transfer direction: 1295 CE to FE 1296 Message Header: 1297 The Message Type in the header is set MessageType= 'Config'. The 1298 ACK flag in the header is can be used by the CE to turn off any 1299 response from the FE. The default behavior is to turn on the ACK 1300 to get the config response from the FE. 1301 Message body: 1302 The Config message body consists of one or more TLVs, the format 1303 of a single (LFB) TLV is as follows: 1305 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 1306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1307 | Type = LFB Operations | Length | 1308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1309 | Reserved/ Event Type | Flags | 1310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1311 | Type ID | Instance ID | 1312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1313 | Config data | 1314 . . 1315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1317 Figure 16 1319 The format for a FE attributes TLV is as follows 1321 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 1322 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1323 |Type = FE operations | Length | 1324 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- 1325 |Reserved/ Event Type | Flags | 1326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1327 | Config data | 1328 . . 1329 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1331 Figure 17 1333 Type (16 bits): 1334 This is a combination of FE, LFB attributes with operations. The 1335 operations include, ADD, DEL, UPDATE/REPLACE, DEL ALL, SUBSCRIBE, 1336 UNSUBSCRIBE, CANCEL. The following Types are defined for this 1337 TLV: 1338 * FE Add, Del, Update, Del All, Cancel, Subscribe, Unsubscribe 1339 events 1340 * LFB Add, Del, Update, Del All, Cancel, Subscribe, Unsubscribe 1341 events 1343 For any of the FE attribute Types, the Type, and Instance ID 1344 fields are not present in this TLV. 1345 Length (16 bits): 1346 Length of the TLV including the T and L fields, in bytes. 1347 Flags (16 bits): 1348 These can be used to indicate Atomicity, Batching, etc. 1349 Type ID (16 bits): 1350 This field uniquely recognizes the LFB type. 1351 Instance ID (16 bits): 1352 This field uniquely identifies the LFB instance. 1353 Config Data (variable length): 1354 This will carry LFB specific data (single or Array LFB specific 1355 entries). The config data might itself be of the form of a TLV. 1356 Event Type (16 bits): 1357 For SUBSCRIBE, UNSUBSCRIBE Events Type TLVs, an Event Type field 1358 will define the Events of interest. Examples of Event Type 1359 include, All Events, FE Events, LFB Events, Packets, Packet 1360 Mirroring. 1362 6.3.2 Config Response Message 1364 This message is sent by the FE to the CE in response to the Config 1365 message. It indicates whether the Config was successful or not on 1366 the FE and also gives a detailed response regarding the configuration 1367 result of each attribute. 1369 Message transfer direction: 1370 FE to CE 1371 Message Header: 1372 The Message Type in the header is set MessageType= 'Config 1373 Response'. The ACK flag in the header is always ignored, because 1374 the config response message will never expect to get any more 1375 response from the message receiver (CE). 1376 Message body: 1377 The Config response message body consists of one or more TLVs, 1378 the format of a single TLV is as follows: 1380 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 1381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1382 | Type = LFB Operations | Length | 1383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1384 | Overall Result | reserved | 1385 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1386 | Type ID | Instance ID | 1387 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1388 | Config Result | 1389 . . 1390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1392 The format for a FE response TLV is as follows 1394 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 1395 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1396 |Type = FE operations | Length | 1397 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1398 | Overall Result | reserved | 1399 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1400 | Config Result | 1401 . . 1402 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1404 Figure 18 1406 Type (16 bits): 1407 Same as that for Config message. For any of the FE attribute 1408 Types, the Type, and Instance ID fields are not present in this 1409 TLV. 1410 Length (16 bits): 1411 Length of the TLV including the T and L fields, in bytes. 1412 Overall Result (16 bits): 1413 This indicates the overall result of the config message, whether 1414 it was successful or it failed. 1415 Type ID (16 bits): 1416 This field uniquely recognizes the LFB type. 1417 Instance ID (16 bits): 1418 This field uniquely identifies the LFB instance. 1419 Config Result (variable length): 1420 This will carry LFB specific results (single or Array LFB 1421 specific result entries). The config result might itself be of 1422 the form of a TLV. 1424 6.4 Event Notification and Response Messages 1425 Editorial Note: If the approach of using an FE Protocol & FE Object 1426 is fully adopted and no other reason for having FE 1427 TLVs is identified, then no distinction will be 1428 further made in the TLV types between FE* and LFB*. 1429 As a result, the Type ID and Instance ID in the TLV 1430 will also be used to identify the FE Protocol 1431 Object, with specific values as mentioned in Section 1432 3.3.2 1434 The Event Notification Message is used for one ForCES element to 1435 asynchronously notify one or more other ForCES elements in the same 1436 ForCES NE on just happened events in it. The Event Notification 1437 Response Message is used for the receiver of the Event Notification 1438 Message to acknowledge the reception of the event notification. 1440 Events in current ForCES protocol can be categorized into following 1441 three types: 1443 o Events happened in CE 1444 o Events happened in FE at the FE coarse layer (in FE protocol 1445 object and FE object) 1446 o Events happened in LFB inside an FE 1448 Events can also be categorized into two classes according to whether 1449 they need subscription or not. An event in one ForCES element that 1450 needs to be subscribed will send notifications to other ForCES 1451 elements only when the other elements have subscribed to the element 1452 for the event notification. How to subscribe/unsubscribe for an 1453 event is described in the Configure Message in Section 6.3. An event 1454 that needs not to be subscribed will always send notifications to 1455 other ForCES elements when the event happens. An event definition 1456 made by ForCES FE model or by vendors will state if the event needs 1457 subscription or not. 1459 Editorial Note: There is an argument that it is preferable to have 1460 all events subscribable. 1462 6.4.1 Event Notification Message 1464 As usual, an Event Notification Message is composed of a common 1465 header and a message body that consists of one or more TLV data 1466 format. Detailed description of the message is as below. 1467 Message Transfer Direction: 1468 FE to CE, or CE to FE 1469 Message Header: 1470 The Message Type in the message header is set to 1471 MessageType = 'EventNotification'. The ACK flag in the header can 1472 be set as: ACK flag ='NoACK'|'SuccessAck'|'UnsuccessACK'|'ACKAll'. 1474 Note that the 'Success' here only means the receiver of the 1475 message has successfully received the message. 1476 Message Body: 1477 The message body for an event notification message consists of (at 1478 least) one or more than one TLVs that describe the notified 1479 events. 1481 According to the different event types described above, the 1482 message body TLV has different data format, which is defined as 1483 follows: 1485 For events generated by CE or by FE coarse layer, the TLV has 1486 following data format: 1488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1489 | Type='FEEventNotification' | Length | 1490 | or 'CEEventNotification' | | 1491 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1492 ~ Event #1 ~ 1493 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1494 ~ Event #2 ~ 1495 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1496 ~ ... ~ 1497 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1498 ~ Event #N ~ 1499 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1501 For events generated by LFB in FE, the TLV has data format as: 1503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1504 | Type='LFBEventNotification' | Length | 1505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1506 | Type ID | Instance ID | 1507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1508 ~ Event #1 ~ 1509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1510 ~ Event #2 ~ 1511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1512 ~ ... ~ 1513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1514 ~ Event #N ~ 1515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1517 Figure 19 1519 Event: 1520 This is a TLV that describes the event to be notified, as follows: 1522 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1523 | Type | Length | 1524 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1525 ~ Description of Event ~ 1526 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1528 Figure 20 1530 Type: 1531 [TBD] 1532 Description of Event: 1533 This field will make a detailed description of the happened event. 1534 The encoding of the description is based on the ForCES FE model if 1535 the event is defined by FE model, or based on vendor 1536 specifications if the event is defined by vendors. Note that the 1537 encoding is responsible for the 32 bits alignment of the 1538 description field.The description will usually include the name 1539 (or the name ID) of the event. It may also include some other 1540 information like parameters that are related to the happened 1541 event. 1543 6.4.2 Event Notification Response Message 1545 After sending out an Event Notification Message, the sender may be 1546 interested in ensuring that the message has been received by 1547 receivers, especially when the sender thinks the event notification 1548 is vital for system management. An Event Notification Response 1549 Message is used for this purpose. The ACK flag in the Event 1550 Notification Message header are used to signal if such acknowledge is 1551 requested or not by the sender. 1553 Detailed description of the message is as below: 1554 Message Transfer Direction: 1555 From FE to CE or from CE to FE, just inverse to the direction of 1556 the Event Notification Message that it responses. 1557 Message Header: 1558 The Message Type in the header is set MessageType= 1559 'EventNotificationResponse'. The ACK flag in the header SHOULD be 1560 set 'NoACK', meaning no further response for the message is 1561 expected. If the ACK flag is set other values, the meaning of the 1562 flag will then be ignored. The Sequence Number in the header 1563 SHOULD keep the same as that of the message to be responded, so 1564 that the event notificatin message sender can keep track of the 1565 responses. 1567 This contains a TLV that describe the response result as below: 1569 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1570 | Type='ResponseResult' | Length | 1571 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1572 | Result | Reason | Code | 1573 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1575 Figure 21 1577 Result: 1578 This describes the reception result of the event notification 1579 message as below: 1581 Result Value Meaning 1582 'Success' The event has been successfully received. 1583 'Unsuccess' The event has not been successfully received. 1585 Reason, Code: 1586 This describes the reason and possible error code when the message 1587 is not successfully received. Note that only the failure at the 1588 protocol layer rather than the transport layer can be allocated 1589 here, that is, if even the header part of the message to be 1590 responded can not be correctly received, the response to the 1591 message will not be able to be generated by the receiver. 1593 Editorial Note: There is a debate on whether the Event 1594 Notification Response Message is necessary or 1595 not. The pro for it is some event notification 1596 senders may be interested in knowing if receivers 1597 have had success/unsuccess receptions of the 1598 events or not. An alternative to generate such 1599 response is for the protocol to define a 1600 universal ACK message so that it can act as 1601 responses for any types of messages as well as 1602 the event notification messages, when the message 1603 senders are interested in knowing whether the 1604 messages have been successfully received or not 1605 (different from the responses for the message 1606 processing results). 1608 6.5 Packet Redirect Message 1610 Packet redirect message is used to transfer data packets between CE 1611 and FE. Usually these data packets are IP packets, though they may 1612 sometimes associated with some metadata generated by other LFBs in 1613 the model, or they may occasionally be other protocol packets, which 1614 usually happen when CE and FE are jointly implementing some 1615 high-touch operations. Packets redirected from FE to CE are the data 1616 packets that come from forwarding plane, and usually are the data 1617 packets that need high-touch operations in CE. Packets redirected 1618 from CE to FE are the data packets that are generated by CE and are 1619 decided by CE to put into forwarding plane in FE. 1621 By properly configuring related LFBs in FE, a packet can also be 1622 mirrored to CE instead of purely redirected to CE, i.e., the packet 1623 is duplicated and one is redirected to CE and the other continues its 1624 way in the LFB topology. 1626 Editorial Note: There are also discussions on how LFBs in FE model 1627 that are related to packet redirect operations 1628 should be defined. Although it is out of the scope 1629 of forces protocol, how to define the LFBs affect 1630 the Packet Redirect Message described here. Because 1631 currently it is still in progress in FE model on how 1632 to define such LFBs, we try to post some thoughts on 1633 this here for discussion. They will be removed 1634 later along with the progress of the FE model work. 1636 Thought 1: To define LFBs called 'RedirectSink' and 1637 'RedirectTap' for packet redirect. 1638 An LFB in FE called 'RedirectSink' is responsible to 1639 collect data packets that need to be redirected to 1640 CE. From the perspective of the FE LFB topology, 1641 the 'RedirectSink' LFB is an LFB with only one input 1642 port and without any output port, and the input port 1643 can then be connected to any other LFB in FE model 1644 by means of a datapath in the forwarding plane. 1645 From the perspective of the ForCES protocol layer, 1646 the 'RedirectSink' LFB will generate the Packet 1647 Redirect Messages when it receives data packets from 1648 forwarding plane. 1650 An LFB in FE called 'RedirectTap' is responsible to 1651 receive data packets that are redirected from CE. 1652 From the perspective of the FE LFB topology, the 1653 'RedirectTap' LFB is an LFB with only one output 1654 port and without any input port, and the output port 1655 can then be connected to any other LFB in FE model 1656 by means of a datapath in the forwarding plane. 1657 From the perspective of ForCES protocol layer, the 1658 'RedirectTap' LFB can receive the Packet Redirect 1659 Messages from CE, and un-encapsulate the data 1660 packets from the message and put them to datapaths 1661 in the forwarding plane. Actually the 'RecirectTap' 1662 LFB acts more like a transcoder that transfers the 1663 ForCES protocol messages to normal data packets in 1664 IP forwarding plane. As a result, if we need to 1665 have redirected packets connected to some LFB (say a 1666 Scheduler) in FE model, we only need to connect the 1667 'RedirectTap LFB to the Scheduler LFB directly via a 1668 datapath as follows: 1670 +-----------------+ +-----------+ 1671 | RedirectTap LFB |------>| | 1672 +-----------------+ | | 1673 | Scheduler | 1674 From other LFB ---->| LFB | 1675 | | 1676 +-----------+ 1678 Figure 23 1680 By use of several 'RedirectSink' LFBs and several 1681 'RedirectTap' LFBs that connect to several different 1682 datapaths in FE forwarding plane, multiple packet 1683 redirect paths between CE and FE can be constructed. 1685 Thought 2: There might be another way a packet could be 1686 redirected: directly by a forwarding path, e.g., by 1687 FPGA/ASIC/NP microcode. In such a case we do not 1688 need to put in a lot of smartness. Probably a link 1689 layer or even network level header is enough. The 1690 receiver demuxes it only based on some protocol type 1691 in the link layer or network transport layer. The 1692 pros for this appraoch is it may provide a fast and 1693 cost-effective path for packet redirect. The cons 1694 for this is it may more or less confuses the Fp 1695 reference point definition in ForCES framework. 1697 We describe the Packet Redirect Message data format in details as 1698 follows: 1699 Message Direction: 1700 CE to FE or FE to CE 1701 Message Header: 1702 The Message Type in the header is set to MessageType= 1703 'PacketRedirect'. The ACK flags in the header SHOULD be set 1704 'NoACK', meaning no response is expected by this message. If the 1705 ACK flag is set other values, the meanings will be ignored. 1707 Message Body: 1708 Consists of one or more TLVs, with every TLV having the following 1709 data format: 1711 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1712 | Type='RedirectData' | Length | 1713 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1714 | Type ID | Instance ID | 1715 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1716 ~ Redirected Data #1 ~ 1717 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1718 ~ Redirected Data #2 ~ 1719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1720 ~ ... ~ 1721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1722 ~ Redirected Data #N ~ 1723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1725 Figure 24 1727 Type ID: 1728 There are only two possible LFB types here, the 'RedirectSink' LFB 1729 or the 'RedirectTap' LFB. If the message is from FE to CE, the 1730 LFB type should be 'RedirectSink'. If the message is from CE to 1731 FE, the LFB type should be 'RedirectTap'. 1732 Instance ID: 1733 Instance ID for the 'RedirectSink' LFB or 'RedirectTap' LFB. 1734 Redirected Data: 1735 This is a TLV describing one packet of data to be directed via the 1736 specified LFB above. The order of the data number is also the 1737 order the data packet arrives the redirector LFB, that is, the 1738 Redirected Data #1 should arrive earlier than the Redirected Data 1739 #2 in this redirector LFB. The TLV format is as follows: 1741 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1742 | Type | Length | 1743 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1744 ~ Description of Redirected Data ~ 1745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1747 Figure 25 1749 Type: 1750 [TBD] 1751 Description of Redirected Data: 1752 This field will make a detailed description of the data to be 1753 redirected as well as the data itself. The encoding of the 1754 description is based on the ForCES FE model if the redirector LFB 1755 is defined by FE model, or based on vendor specifications if the 1756 redirector LFB is defined by vendors. The description will 1757 usually include the name (or the name ID) of the redirected packet 1758 data (such as 'IPv4 Packet', 'IPv6 Packet'), and the packet data 1759 itself. It may also include some metadata (metadata name (or name 1760 ID) and its value)associated with the redirected data packet. 1762 6.6 State Maintenance Messages 1764 The State Maintenance Messages are used by the CE to change state 1765 related information on the FE. 1767 Editorial Note: As work progresses in defining the FE model, it may 1768 happen that the messages defined here (State 1769 Maintenance messages) become redundant. For 1770 instance, FE activation/deactivation may be 1771 performed by configuring the FE State attribute in 1772 the FE Object. Such inconsistencies will be 1773 resolved 1775 6.6.1 State Maintenance Message 1777 This message is sent by the CE to change the state of the FE, e.g. 1778 to Activate/Deactivate the FE, shutdown the FE, etc. 1779 Message transfer direction: 1780 CE to FE 1781 Message Header: 1782 The Message Type in the header is set MessageType= 'State 1783 Maintenance'. The ACK flag in the header is can be used by the 1784 CE to turn off any response from the FE. The default behavior is 1785 to turn on the ACK to get the state maintenance response from the 1786 FE. 1787 Message body: 1788 The state maintenance message body consists of one or more TLVs, 1789 the format of a single TLV is as follows: 1791 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 1792 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1793 |Type= FE De/Activate,Shutdown | Length | 1794 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1795 | TBD | 1796 . . 1797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1799 Figure 26 1801 Type (16 bits): 1802 These can be FE Activate, FE Deactivate, Shutdown FE. Activating 1803 an FE means asking it to forward packets, Deactivate means the FE 1804 stops forwarding packets. The default state of the FE is 1805 deactivated till it explicitly activated by the CE. 1806 Editorial Note: These Types may be extended to include LFB 1807 Activate/Deactivate as well. However this is 1808 still being discussed. 1809 Length (16 bits): 1810 Length of the TLV including the T and L fields, in bytes. 1811 FE State object (variable): 1812 This is an TLV which can be defined and extended to represent FE 1813 specific state information. It will contain information such as 1814 the HA Mode, Primary CE ID, etc for the FE. 1816 6.6.2 State Maintenance Response Message 1818 This message is sent by the FE to the CE in response to the state m. 1819 message. It indicates whether the state m. was successful or not on 1820 the FE. 1821 Message transfer direction: 1822 FE to CE 1823 Message Header: 1824 The Message Type in the header is set MessageType= 'state m. 1825 Response'. The ACK flag in the header is always ignored, because 1826 the state m. response message will never expect to get any more 1827 response from the message receiver (CE). 1828 Message body: 1829 The state maintenance response message body consists of one or 1830 more TLVs, the format of a single TLV is as follows: 1832 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 1833 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1834 |Type= S.M.Result | Length | 1835 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1836 | Result | Reserved | 1837 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1839 Figure 27 1841 Type (16 bits): 1842 Same as that for state maintenance message. 1843 Length (16 bits): 1844 Length of the TLV including the T and L fields, in bytes. 1846 Overall Result (16 bits): 1847 This indicates the overall result of the state maintenance 1848 message, whether it was successful or it failed. 1850 6.7 Heartbeat Message 1852 The Heartbeat (HB) Message is used for one ForCES element (FE or CE) 1853 to asynchronously notify one or more other ForCES elements in the 1854 same ForCES NE on its liveness. 1856 A Heartbeat Message is sent by a ForCES element periodically. The 1857 time interval to send the message is set by the Association Setup 1858 Message described in Section 6.1.1. A little different from other 1859 protocol messages, a Heartbeat messge is only composed of a common 1860 header, withe the message body left empty. Detailed description of 1861 the message is as below. 1862 Message Transfer Direction: 1863 FE to CE, or CE to FE 1864 Message Header: 1865 The Message Type in the message header is set to MessageType = 1866 'Heartbeat'. The ACK flag in the header SHOULD be set to 1867 'NoACK', meaning no response from receiver(s) is expected by the 1868 message sender. Other values of the ACK flag will always be 1869 ignored by the message receiver. 1870 Message Body: 1871 The message body is empty for the Heartbeat Message, so as to 1872 grasp more efficiency for message transportation and processing. 1874 7. Protocol Scenarios 1876 7.1 Association Setup state 1878 The associations among CEs and FEs are initiated via Association 1879 setup message from the FE. If a setup request is granted by the CE, 1880 a successful setup response message is sent to the FE. If CEs and 1881 FEs are operating in an insecure environment then the security 1882 association have to be established between them before any 1883 association messages can be exchanged. The TML will take care of 1884 establishing any security associations. 1886 This is followed by capability query, topology query. When the FE is 1887 ready to start forwarding data traffic, it sends a FE UP Event 1888 message to the CE. The CE responds with a FE ACTIVATE State 1889 Maintenance message to ask the FE to go active and start forwarding 1890 data traffic. At this point the association establishment is 1891 complete. These sequences of messages are illustrated in the Figure 1892 below. 1894 FE PL CE PL 1896 | | 1897 | Asso Setup Req | 1898 |---------------------->| 1899 | | 1900 | Asso Setup Resp | 1901 |<----------------------| 1902 | | 1903 | Capability Query | 1904 |<----------------------| 1905 | | 1906 | Query Resp | 1907 |---------------------->| 1908 | | 1909 | Topo Query | 1910 |<----------------------| 1911 | | 1912 | Topo Query Resp | 1913 |---------------------->| 1914 | | 1915 | FE UP Event | 1916 |---------------------->| 1917 | | 1918 | S.M. Activate FE | 1919 |<----------------------| 1920 | | 1922 Figure 28: Message exchange between CE and FE to establish an NE 1923 association 1925 On successful completion of this state, the FE joins the NE and is 1926 moved to the Established State or Steady state. 1928 7.2 Association Established state or Steady State 1930 In this state the FE is continously updated or queried. The FE may 1931 also send asynchronous event notifications to the CE or synchronous 1932 heartbeat messages. This continues until a termination (or 1933 deactivation) is initiated by either the CE or FE. Figure below 1934 helps illustrate this state. 1936 FE PL CE PL 1938 | | 1939 | Heart Beat | 1940 |<----------------------| 1941 | | 1942 | Heart Beat | 1943 |---------------------->| 1944 | | 1945 | Config-Subscribe Ev | 1946 |<----------------------| 1947 | | 1948 | Config Resp | 1949 |---------------------->| 1950 | | 1951 | Config-Add LFB Attr | 1952 |<----------------------| 1953 | | 1954 | Config Resp | 1955 |---------------------->| 1956 | | 1957 | Query LFB Stats | 1958 |<----------------------| 1959 | | 1960 | Query Resp | 1961 |---------------------->| 1962 | | 1963 | FE Event Report | 1964 |---------------------->| 1965 | | 1966 | Config-Del LFB Attr | 1967 |<----------------------| 1968 | | 1969 | Config Resp | 1970 |---------------------->| 1971 | | 1972 | Packet Redirect | 1973 |---------------------->| 1974 | | 1975 | Heart Beat | 1976 |<----------------------| 1977 . . 1978 . . 1979 | | 1980 | S.M. FE Deactivate | 1981 |<----------------------| 1982 | | 1984 Figure 29: Message exchange between CE and FE during steady-state 1985 communication 1987 Note that the sequence of messages shown in the figure serve only as 1988 examples and the messages exchange sequences could be different from 1989 what is shown in the figure. Also, note that the protocol scenarios 1990 described in this section do not include all the different message 1991 exchanges which would take place during failover. That is described 1992 in the HA section 8. 1994 8. High Availability Support 1996 Editorial Note: This section currently focuses only on CE-CE 1997 redundancy. We need to further discuss the FE-FE 1998 view. We also need to discuss Multiple Primary CEs. 2000 The ForCES protocol provides mechanisms for CE redundancy and 2001 failover, in order to support High Availability. There can be 2002 multiple redundant CEs and FEs in a ForCES NE. However, at any time 2003 there can only be one Primary CE controlling the FEs and there can be 2004 multiple secondary CEs. The FE and the CE PL are aware of the 2005 primary and secondary CEs. This information (primary, secondary CEs) 2006 is configured in the FE, CE PLs during pre-association by FEM, CEM 2007 respectively. Only the primary CE sends Control messages to the FEs. 2008 The FE may send its event reports, redirection packets to only the 2009 Primary CE (Report Primary Mode) or it may send these to both primary 2010 and secondary CEs (Report All Mode). (The latter helps with keeping 2011 state between CEs synchronized, although it does not guarantee 2012 synchronization.) This behavior or HA Modes are configured during 2013 Association setup phase but can be changed by the CE anytime during 2014 protocol operation. A CE-to-CE synchronization protocol will be 2015 needed in most cases to support fast failover, however this will not 2016 be defined by the ForCES protocol. 2018 During a communication failure between the FE and CE (which is caused 2019 due to CE or link reasons, i.e. not FE related), the TML on the FE 2020 will trigger the FE PL regarding this failure. The FE PL will send a 2021 message (Event Report) to the Secondary CEs to indicate this failure 2022 or the CE PL will detect this and one of the Secondary CEs takes over 2023 as the primary CE for the FE. An explicit message (State Maintenance 2024 Move command) from the primary CE, can also be used to change the 2025 Primary CE for an FE during normal protocol operation. In order to 2026 support fast failover, the FE will establish association (setup msg) 2027 as well as complete the capability exchange with the Primary as well 2028 as all the Secondary CEs (in all scenarios/modes). 2030 These two scenarios (Report All, Report Primary) have been 2031 illustrated in the figures below. 2033 FE CE Primary CE Secondary 2034 | | | 2035 | Asso Estb,Caps exchg | | 2036 1 |<--------------------->| | 2037 | | | 2038 | Asso Estb,Caps|exchange | 2039 2 |<----------------------|------------------->| 2040 | | | 2041 | All msgs | | 2042 3 |<--------------------->| | 2043 | | | 2044 | packet redirection,|events, HBs | 2045 4 |-----------------------|------------------->| 2046 | | | 2047 | FAILURE | 2048 | | 2049 | Event Report (pri CE down) | 2050 5 |------------------------------------------->| 2051 | | 2052 | All Msgs | 2053 6 |------------------------------------------->| 2055 Figure 30: CE Failover for Report All mode 2056 FE CE Primary CE Secondary 2057 | | | 2058 | Asso Estb,Caps exchg | | 2059 1 |<--------------------->| | 2060 | | | 2061 | Asso Estb,Caps|exchange | 2062 2 |<----------------------|------------------->| 2063 | | | 2064 | All msgs | | 2065 3 |<--------------------->| | 2066 | | | 2067 | (HeartBeats| only) | 2068 4 |-----------------------|------------------->| 2069 | | | 2070 | FAILURE | 2071 | | 2072 | Event Report (pri CE down) | 2073 5 |------------------------------------------->| 2074 | | 2075 | All Msgs | 2076 6 |------------------------------------------->| 2078 Figure 31: CE Failover for Report Primary Mode 2080 8.1 Responsibilities for HA 2082 TML level - Transport level: 2083 1. The TML controls logical connection availability and failover. 2084 2. The TML also controls peer HA managements. 2086 At this level, control of all lower layers example transport level 2087 (such as IP addresses, MAC addresses etc) and associated links going 2088 down are the role of the TML. 2090 PL Level: 2091 All the other functionality including configuring the HA behavior 2092 during setup, the CEIDs are used to identify primary, secondary CEs, 2093 protocol Messages used to report CE failure (Event Report), Heartbeat 2094 messages used to detect association failure, messages to change 2095 primary CE (state maintenance move), and other HA related operations 2096 described before are the PL responsibility. 2098 To put the two together, if a path to a primary CE is down, the TML 2099 would take care of failing over to a backup path, if one is 2100 available. If the CE is totally unreachable then the PL would be 2101 informed and it will take the appropriate actions described before. 2103 9. Security Considerations 2105 ForCES architecture identified several [Reference Arch] levels of 2106 security. ForCES PL uses security services provided by the ForCES 2107 TML layer. TML layer provides security services such as endpoint 2108 authentication service, message authentication service and 2109 confidentiality service. Endpoint authentication service is invoked 2110 at the time of pre-association connection establishment phase and 2111 message authentication is performed whenever FE or CE receives a 2112 packet from its peer. 2114 Following are the general security mechanism that needs to be in 2115 place for ForCES PL layer. 2116 o Security mechanism are session controlled that is once the 2117 security is turned ON depending upon the chosen security level (No 2118 Security, Authentication only, Confidentiality), it will be in 2119 effect for the entire duration of the session. 2120 o Operator should configure the same security policies for both 2121 primary and backup FE's and CE's (if available). This will ensure 2122 uniform operations, and to avoid unnecessary complexity in policy 2123 configuration. 2124 o ForCES PL endpoints SHOULD pre-established connections with both 2125 primary and backup CE's. This will reduce the security messages 2126 and enable rapid switchover operations for HA. 2128 9.1 No Security 2130 When No security is chosen for ForCES protocol communication, both 2131 endpoint authentication and message authentication service needs be 2132 performed by ForCES PL layer. Both these mechanism are weak and does 2133 not involve cryptographic operation. Operator can choose "No 2134 security" level when the ForCES protocol endpoints are within an 2135 single box. 2137 In order to have interoperable and uniform implementation across 2138 various security levels, each CE and FE endpoint MUST implement this 2139 level. The operations that are being performed for "No security" 2140 level is required even if lower TML security services are being used. 2142 9.1.1 Endpoint Authentication 2144 Each CE and FE PL layer maintain set of associations list as part of 2145 configuration. This is done via CEM and FEM interfaces. FE MUST 2146 connect to only those CE's that are configured via FEM similarly CE 2147 should accept the connection and establish associations for the FE's 2148 which are configured via CEM. CE should validate the FE identifier 2149 before accepting the connection during the pre-association phase. 2151 9.1.2 Message authentication 2153 When CE or FE generates initiates a message, the receiving endpoint 2154 MUST validate the initiator of the message by checking the common 2155 header CE or FE identifiers. This will ensure proper protocol 2156 functioning. We recommend this extra step processing even if the 2157 underlying TLM layer security services. 2159 9.2 ForCES PL and TML security service 2161 This section is applicable if operator wishes to use the TML security 2162 services. ForCES TML layer MUST support one or more security service 2163 such as endpoint authentication service, message authentication 2164 service, confidentiality service as part of TML security layer 2165 functions. It is the responsibility of the operator to select 2166 appropriate security service and configure security policies 2167 accordingly. The details of such configuration is outside the scope 2168 of ForCES PL and is depending upon the type of transport protocol, 2169 nature of connection. 2171 All these configurations should be done prior to starting the CE and 2172 FE. 2174 When certificates-based authentication is being used at TML layer, 2175 the certificate can use ForCES specific naming structure as 2176 certificate names and accordingly the security policies can be 2177 configured at CE and FE. 2179 9.2.1 Endpoint authentication service 2181 When TML security services are enabled. ForCES TML layer performs 2182 endpoint authentication. Security association is established between 2183 CE and FE and is transparent to the ForCES PL layer. 2185 We recommend that FE after establishing the connection with the 2186 primary CE, should establish the security association with the backup 2187 CE (if available). During the switchover operation CE's security 2188 state associated with each SA's are not transferred. SA between 2189 primary CE and FE and backup CE and FE are treated as two separate 2190 SA's. 2192 9.2.2 Message authentication service 2194 This is TML specific operation and is transparent to ForCES PL 2195 layer[TML document]. 2197 9.2.3 Confidentiality service 2199 This is TML specific operation and is transparent to ForCES PL 2200 layer.[TML document] 2202 10. References 2204 10.1 Normative References 2206 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 2207 June 1999. 2209 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 2210 of IP Control and Forwarding", RFC 3654, November 2003. 2212 [RFC3746] Yang, L., Dantu, R., Anderson, T. and R. Gopal, 2213 "Forwarding and Control Element Separation (ForCES) 2214 Framework", RFC 3746, April 2004. 2216 10.2 Informational References 2218 [FE-MODEL] 2219 Yang, L., "ForCES Forwarding Element Model", Feb. 2004. 2221 Author's Address 2223 Avri Doria 2224 ETRI 2226 Phone: +1 401 663 5024 2227 EMail: avri@acm.org 2229 Appendix A. Individual Authors/Editors Contact 2231 The participants in the ForCES Protocol Team: 2233 +--------------------+------------------------------+ 2234 | Author | Email | 2235 +--------------------+------------------------------+ 2236 | Ligang Dong | donglg@mail.hzic.edu.cn | 2237 | | | 2238 | Avri Doria | avri@acm.org | 2239 | | | 2240 | Ram Gopal | ram.gopal@nokia.com | 2241 | | | 2242 | Robert Haas | rha@zurich.ibm.com | 2243 | | | 2244 | Jamal Hadi Salim | hadi@znyx.com | 2245 | | | 2246 | Hormuzd M Khosravi | hormuzd.m.khosravi@intel.com | 2247 | | | 2248 | Weiming Wang | wmwang@mail.hzic.edu.cn | 2249 +--------------------+------------------------------+ 2251 Table 1 2253 Appendix B. IANA considerations 2255 tbd 2257 Appendix C. Implementation Notes 2259 C.1 TML considerations 2261 Having separated the PL from the TML layer, it became clear that the 2262 TML layer needed to understand the desires of the PL layer to service 2263 it. Example: How does the TML layer map prioritization or 2264 reliability needs of a PL message? To see the challenge involved, 2265 assume that all of the FE TML, FE PL, CE TML and CE PL are 2266 implemented by different authors probably belonging to different 2267 organizations. Three implementation alternatives were discussed. 2269 As an example, consider a TML which defines that PL messages needing 2270 reliability get sent over a TCP connection; then TML-PL interfaces 2271 are: 2272 o PL to call a special API: example send_reliable(msg) which is 2273 translated by the TML to mean send via TCP. 2274 o PL to call a generic API: example send(msg) with explicit msg 2275 flags turned to say "reliability needed" and the TML translates 2276 this to mean send via TCP. 2277 o PL sends the Forces Messages such a message is inferred to mean 2278 send via TCP by the TML. 2280 in #1 and #2 the msg includes a ForCES msg with metadata flags which 2281 are consumed by the TML layer. 2283 #3 is a technique that will be referred as inference-by-TML 2284 technique. It simplifies the standardization effort since both #1 2285 and #2 will require standardization of an API. Two ideas discussed 2286 for TML inference of PL messages are: 2287 1. Looking at the flags in the header. 2288 2. Looking at the message type. 2290 #1 and #2 can still be used if a single organization implements both 2291 (PL and TML) layers. It is also reasonable that one organization 2292 implements the TML and provides an abstraction to another 2293 organization to implement a PL layer on. 2295 C.1.1 PL Flag inference by TML 2296 1. Reliability 2297 This could be "signalled" from the PL to the TML via the ACK 2298 flag. The message type as well could be used to indicate this. 2299 2. No reliability 2300 Could be signalled via missing ACK flag. The message type as 2301 well could be used to indicate this. 2302 3. Priorities 2303 A remapping to be defined via the FEM or the CEM interface 2304 depending on the number of TML priorities available. 2306 4. Addressing 2307 This is TML specific. For example a TML that is capable of 2308 multicast transport may map a multicast PL ID to a multicast 2309 transport address. 2310 5. Event notifications 2311 The TML must be able to send to the PL notifications. 2312 1. The TML should be able to send Transport level congestion 2313 notifications to the PL. 2314 2. Link events for HA purposes if configuration requires it 2315 3. Events that will trigger PL layer events from the TML. 2316 As an example, an HA event at the TML layer like a failure of 2317 CE detected at TML on the FE may belong to this. In this 2318 case, a PL event msg will be triggered and sent to CE. 2319 4. Events that are intrinsic to the same CE or FE a TML is 2320 located. These will not trigger any PL msg, instead, they 2321 just act as notification to PL core (FE object). The 2322 congestion event generated at the transmission source side 2323 may belong to this, because it usually only needs to tell the 2324 upper PL at the same side rather than the opposite side that 2325 congestion has happened along the path. E.g., a congestion 2326 event at CE TML layer only need to tell CE PL of this, rather 2327 than the opposite FE via a PL msg. 2329 C.1.2 Message type inference to Mapping at the TML 2331 In this case one would define the desires of the different message 2332 types and what they expect from the TML. For example: 2333 1. Association Setup, Teardown, Config, Query the PL will expect the 2334 following services from TML: Reliable delivery and highest 2335 prioritization. 2336 2. Packet Redirect, HB Message Types, and Event Reports the PL will 2337 require the following services from TML: Medium Prioritization, 2338 and notifications when excessive losses are reached. 2340 Intellectual Property Statement 2342 The IETF takes no position regarding the validity or scope of any 2343 Intellectual Property Rights or other rights that might be claimed to 2344 pertain to the implementation or use of the technology described in 2345 this document or the extent to which any license under such rights 2346 might or might not be available; nor does it represent that it has 2347 made any independent effort to identify any such rights. Information 2348 on the procedures with respect to rights in RFC documents can be 2349 found in BCP 78 and BCP 79. 2351 Copies of IPR disclosures made to the IETF Secretariat and any 2352 assurances of licenses to be made available, or the result of an 2353 attempt made to obtain a general license or permission for the use of 2354 such proprietary rights by implementers or users of this 2355 specification can be obtained from the IETF on-line IPR repository at 2356 http://www.ietf.org/ipr. 2358 The IETF invites any interested party to bring to its attention any 2359 copyrights, patents or patent applications, or other proprietary 2360 rights that may cover technology that may be required to implement 2361 this standard. Please address the information to the IETF at 2362 ietf-ipr@ietf.org. 2364 Disclaimer of Validity 2366 This document and the information contained herein are provided on an 2367 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2368 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2369 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2370 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2371 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2372 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2374 Copyright Statement 2376 Copyright (C) The Internet Society (2004). This document is subject 2377 to the rights, licenses and restrictions contained in BCP 78, and 2378 except as set forth therein, the authors retain all their rights. 2380 Acknowledgment 2382 Funding for the RFC Editor function is currently provided by the 2383 Internet Society.