idnits 2.17.1 draft-ietf-forces-protocol-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1.a on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2520. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2497. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2504. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2510. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: This document is an Internet-Draft and is subject to all provisions of Section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 57 longer pages, the longest (page 1) being 68 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 65 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 174 instances of too long lines in the document, the longest one being 4 characters in excess of 72. ** 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 593: '... the transaction MUST arrive at the de...' RFC 2119 keyword, line 602: '...nt for a transaction MUST be met. 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 935: '...se default values MUST be used for the...' (12 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 489 has weird spacing: '...ing are scena...' -- 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 (October 25, 2004) is 7116 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 1889, but not defined == Unused Reference: 'RFC2629' is defined on line 2305, 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: 10 errors (**), 0 flaws (~~), 7 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: April 25, 2005 October 25, 2004 5 ForCES Protocol Specification 6 draft-ietf-forces-protocol-01.txt 8 Status of this Memo 10 This document is an Internet-Draft and is subject to all provisions 11 of section 3 of RFC 3667. By submitting this Internet-Draft, each 12 author represents that any applicable patent or other IPR claims of 13 which he or she is aware have been or will be disclosed, and any of 14 which he or she become aware will be disclosed, in accordance with 15 RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on April 25, 2005. 35 Copyright Notice 37 Copyright (C) The Internet Society (2004). 39 Abstract 41 This specification documents the Forwarding and Control Element 42 Separation protocol. This protocol is designed to be used between a 43 Control Element and a Forwarding Element in a Routing Network 44 Element. 46 Authors 48 The participants in the ForCES Protocol Team, co-authors and 49 co-editors, of this draft, are: 51 Ligang Dong (Zhejiang Gongshang University), Avri Doria (ETRI), Ram 52 Gopal (Nokia), Robert Haas (IBM), Jamal Hadi Salim (Znyx), Hormuzd M 53 Khosravi (Intel), and Weiming Wang (Zhejiang Gongshang University). 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 58 1.1 Sections of this document . . . . . . . . . . . . . . . . 4 59 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 5 60 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 61 3.1 Protocol Framework . . . . . . . . . . . . . . . . . . . . 8 62 3.1.1 The PL layer . . . . . . . . . . . . . . . . . . . . . 10 63 3.1.2 The TML layer . . . . . . . . . . . . . . . . . . . . 11 64 3.1.3 The FEM/CEM Interface . . . . . . . . . . . . . . . . 11 65 3.2 ForCES Protocol Phases . . . . . . . . . . . . . . . . . . 12 66 3.2.1 Pre-association . . . . . . . . . . . . . . . . . . . 12 67 3.2.2 Post-association . . . . . . . . . . . . . . . . . . . 13 68 3.3 Protocol Mechanisms . . . . . . . . . . . . . . . . . . . 14 69 3.3.1 Of Transactions, Atomicity and 2 Phase Commits . . . . 14 70 3.3.2 FE, CE, and FE protocol LFBs . . . . . . . . . . . . . 15 71 3.3.3 Scaling by Concurrency . . . . . . . . . . . . . . . . 15 72 4. TML Requirements . . . . . . . . . . . . . . . . . . . . . . . 17 73 4.1 TML Parameterization . . . . . . . . . . . . . . . . . . . 18 74 5. Common Header . . . . . . . . . . . . . . . . . . . . . . . . 19 75 6. Protocol Messages . . . . . . . . . . . . . . . . . . . . . . 22 76 6.1 Core ForCES LFBs . . . . . . . . . . . . . . . . . . . . . 22 77 6.1.1 FE Protocol LFB . . . . . . . . . . . . . . . . . . . 23 78 6.1.2 FE LFB . . . . . . . . . . . . . . . . . . . . . . . . 23 79 6.1.3 CE LFB . . . . . . . . . . . . . . . . . . . . . . . . 24 80 6.2 Association Messages . . . . . . . . . . . . . . . . . . . 25 81 6.2.1 Association Setup Message . . . . . . . . . . . . . . 25 82 6.2.2 Association Setup Response Message . . . . . . . . . . 27 83 6.2.3 Association Teardown Message . . . . . . . . . . . . . 29 84 6.3 Configuration Messages . . . . . . . . . . . . . . . . . . 30 85 6.3.1 Config Message . . . . . . . . . . . . . . . . . . . . 30 86 6.3.2 Config Response Message . . . . . . . . . . . . . . . 32 87 6.4 Query and Query Response Messages . . . . . . . . . . . . 34 88 6.4.1 Query Message . . . . . . . . . . . . . . . . . . . . 34 89 6.4.2 Query Response Message . . . . . . . . . . . . . . . . 36 90 6.5 Event Notification and Response Messages . . . . . . . . . 37 91 6.5.1 Event Notification Message . . . . . . . . . . . . . . 38 92 6.5.2 Event Notification Response Message . . . . . . . . . 40 93 6.6 Packet Redirect Message . . . . . . . . . . . . . . . . . 41 94 6.7 Heartbeat Message . . . . . . . . . . . . . . . . . . . . 45 95 6.8 Operation Summary . . . . . . . . . . . . . . . . . . . . 45 96 7. Protocol Scenarios . . . . . . . . . . . . . . . . . . . . . . 47 97 7.1 Association Setup state . . . . . . . . . . . . . . . . . 47 98 7.2 Association Established state or Steady State . . . . . . 48 99 8. High Availability Support . . . . . . . . . . . . . . . . . . 51 100 8.1 Responsibilities for HA . . . . . . . . . . . . . . . . . 53 101 9. Security Considerations . . . . . . . . . . . . . . . . . . . 54 102 9.1 No Security . . . . . . . . . . . . . . . . . . . . . . . 54 103 9.1.1 Endpoint Authentication . . . . . . . . . . . . . . . 54 104 9.1.2 Message authentication . . . . . . . . . . . . . . . . 55 105 9.2 ForCES PL and TML security service . . . . . . . . . . . . 55 106 9.2.1 Endpoint authentication service . . . . . . . . . . . 55 107 9.2.2 Message authentication service . . . . . . . . . . . . 55 108 9.2.3 Confidentiality service . . . . . . . . . . . . . . . 56 109 10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . 57 110 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 58 111 11.1 Normative References . . . . . . . . . . . . . . . . . . . . 58 112 11.2 Informational References . . . . . . . . . . . . . . . . . . 58 113 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 58 114 A. Individual Authors/Editors Contact . . . . . . . . . . . . . . 59 115 B. IANA considerations . . . . . . . . . . . . . . . . . . . . . 61 116 C. Implementation Notes . . . . . . . . . . . . . . . . . . . . . 62 117 C.1 TML considerations . . . . . . . . . . . . . . . . . . . . 62 118 C.1.1 PL Flag inference by TML . . . . . . . . . . . . . . . 62 119 C.1.2 Message type inference to Mapping at the TML . . . . . 63 120 D. Changes between -00 and -01 . . . . . . . . . . . . . . . . . 64 121 Intellectual Property and Copyright Statements . . . . . . . . 65 123 1. Introduction 125 This specification provides a draft definition of an IP-based 126 protocol for Control Element control of an Forwarding Element. The 127 protocol is a TLV based protocol that include commands for transport 128 of LFB information as well as TLVs for association, configuration, 129 status, and events. 131 This specification does not specify a transport mechanism for 132 messages, but does include a discussion of the services that must be 133 provided by the transport interface. 135 1.1 Sections of this document 137 Section 2 provides a glossary of terminology used in the 138 specification. 140 Section 3 provides an overview of the protocol including a discussion 141 on the protocol framework, descriptions of the protocol layer (PL) 142 and a transport mapping layer (TML), as well as of the ForCES 143 protocol mechanisms. 145 While this document does not define the TML, Section 4 details the 146 services that the TML must provide. 148 The Forces protocol is defined to have a common header for all other 149 message types. The header is defined in Section 5, while the 150 protocol messages are defined in Section 6. 152 Section 7 describes several Protocol Scenarios and includes message 153 exchange descriptions. 155 Section 8 describes mechanism in the protocol to support high 156 availability mechanisms including redundancy and fail over. Section 157 9 defines the security mechanisms provided by the PL and TML. 159 2. Definitions 161 This document follows the terminology defined by the ForCES 162 Requirements in [RFC3654] and by the ForCES framework in [RFC3746]. 163 This document also uses the terminology defined by ForCES FE model in 164 [FE-MODEL]. We copy the definitions of some of the terminology as 165 indicated below: 167 Addressable Entity (AE) - A physical device that is directly 168 addressable given some interconnect technology. For example, on IP 169 networks, it is a device to which we can communicate using an IP 170 address; and on a switch fabric, it is a device to which we can 171 communicate using a switch fabric port number. 173 Forwarding Element (FE) - A logical entity that implements the ForCES 174 protocol. FEs use the underlying hardware to provide per-packet 175 processing and handling as directed/controlled by a CE via the ForCES 176 protocol. 178 Control Element (CE) - A logical entity that implements the ForCES 179 protocol and uses it to instruct one or more FEs how to process 180 packets. CEs handle functionality such as the execution of control 181 and signaling protocols. 183 Pre-association Phase - The period of time during which a FE Manager 184 (see below) and a CE Manager (see below) are determining which FE and 185 CE should be part of the same network element. 187 Post-association Phase - The period of time during which a FE does 188 know which CE is to control it and vice versa, including the time 189 during which the CE and FE are establishing communication with one 190 another. 192 FE Model - A model that describes the logical processing functions 193 of a FE. 195 FE Manager (FEM) - A logical entity that operates in the 196 pre-association phase and is responsible for determining to which 197 CE(s) a FE should communicate. This process is called CE discovery 198 and may involve the FE manager learning the capabilities of available 199 CEs. A FE manager may use anything from a static configuration to a 200 pre-association phase protocol (see below) to determine which CE(s) 201 to use. Being a logical entity, a FE manager might be physically 202 combined with any of the other logical entities such as FEs. 204 CE Manager (CEM) - A logical entity that operates in the 205 pre-association phase and is responsible for determining to which 206 FE(s) a CE should communicate. This process is called FE discovery 207 and may involve the CE manager learning the capabilities of available 208 FEs. A CE manager may use anything from a static configuration to a 209 pre-association phase protocol (see below) to determine which FE to 210 use. Being a logical entity, a CE manager might be physically 211 combined with any of the other logical entities such as CEs. 213 ForCES Network Element (NE) - An entity composed of one or more CEs 214 and one or more FEs. To entities outside a NE, the NE represents a 215 single point of management. Similarly, a NE usually hides its 216 internal organization from external entities. 218 High Touch Capability - This term will be used to apply to the 219 capabilities found in some forwarders to take action on the contents 220 or headers of a packet based on content other than what is found in 221 the IP header. Examples of these capabilities include NAT-PT, 222 firewall, and L7 content recognition. 224 Datapath -- A conceptual path taken by packets within the forwarding 225 plane inside an FE. 227 LFB (Logical Function Block) type -- A template representing a 228 fine-grained, logically separable and well-defined packet processing 229 operation in the datapath. LFB types are the basic building blocks 230 of the FE model. 232 LFB (Logical Function Block) Instance -- As a packet flows through an 233 FE along a datapath, it flows through one or multiple LFB instances, 234 with each implementing an instance of a certain LFB type. There may 235 be multiple instances of the same LFB in an FE's datapath. Note that 236 we often refer to LFBs without distinguishing between LFB type and 237 LFB instance when we believe the implied reference is obvious for the 238 given context. 240 LFB Metadata -- Metadata is used to communicate per-packet state from 241 one LFB to another, but is not sent across the network. The FE model 242 defines how such metadata is identified, produced and consumed by the 243 LFBs, but not how metadata is encoded within an implementation. 245 LFB Attribute -- Operational parameters of the LFBs that must be 246 visible to the CEs are conceptualized in the FE model as the LFB 247 attributes. The LFB attributes include, for example, flags, single 248 parameter arguments, complex arguments, and tables that the CE can 249 read or/and write via the ForCES protocol (see below). 251 LFB Topology -- Representation of how the LFB instances are logically 252 interconnected and placed along the datapath within one FE. 253 Sometimes it is also called intra-FE topology, to be distinguished 254 from inter-FE topology. 256 FE Topology -- A representation of how the multiple FEs within a 257 single NE are interconnected. Sometimes this is called inter-FE 258 topology, to be distinguished from intra-FE topology (i.e., LFB 259 topology). 261 Inter-FE Topology -- See FE Topology. 263 Intra-FE Topology -- See LFB Topology. 265 Following terminologies are defined by this document: 267 ForCES Protocol - While there may be multiple protocols used within 268 the overall ForCES architecture, the term "ForCES protocol" refers 269 only to the protocol used at the Fp reference point in the ForCES 270 Framework in RFC3746 [RFC3746]. This protocol does not apply to 271 CE-to-CE communication, FE-to-FE communication, or to communication 272 between FE and CE managers. Basically, the ForCES protocol works in 273 a master-slave mode in which FEs are slaves and CEs are masters. 274 This document defines the specifications for this ForCES protocol. 276 ForCES Protocol Layer (ForCES PL) -- A layer in ForCES protocol 277 architecture that defines the ForCES protocol messages, the protocol 278 state transfer scheme, as well as the ForCES protocol architecture 279 itself (including requirements of ForCES TML (see below)). 280 Specifications of ForCES PL are defined by this document. 282 ForCES Protocol Transport Mapping Layer (ForCES TML) -- A layer in 283 ForCES protocol architecture that specifically addresses the protocol 284 message transportation issues, such as how the protocol messages are 285 mapped to different transport media (like TCP, IP, ATM, Ethernet, 286 etc), and how to achieve and implement reliability, multicast, 287 ordering, etc. The ForCES TML is specifically addressed in a 288 separate ForCES TML Specification document. 290 3. Overview 292 The reader is referred to the Framework document [RFC3746], and in 293 particular sections 3 and 4, for an architectural overview and an 294 explanation of how the ForCES protocol fits in. There may be some 295 content overlap between the framework document and this section in 296 order to provide clarity. 298 3.1 Protocol Framework 300 Figure 1 below is reproduced from the Framework document for clarity. 301 It shows a NE with two CEs and two FEs. 303 --------------------------------------- 304 | ForCES Network Element | 305 -------------- Fc | -------------- -------------- | 306 | CE Manager |---------+-| CE 1 |------| CE 2 | | 307 -------------- | | | Fr | | | 308 | | -------------- -------------- | 309 | Fl | | | Fp / | 310 | | Fp| |----------| / | 311 | | | |/ | 312 | | | | | 313 | | | Fp /|----| | 314 | | | /--------/ | | 315 -------------- Ff | -------------- -------------- | 316 | FE Manager |---------+-| FE 1 | Fi | FE 2 | | 317 -------------- | | |------| | | 318 | -------------- -------------- | 319 | | | | | | | | | | 320 ----+--+--+--+----------+--+--+--+----- 321 | | | | | | | | 322 | | | | | | | | 323 Fi/f Fi/f 325 Fp: CE-FE interface 326 Fi: FE-FE interface 327 Fr: CE-CE interface 328 Fc: Interface between the CE Manager and a CE 329 Ff: Interface between the FE Manager and an FE 330 Fl: Interface between the CE Manager and the FE Manager 331 Fi/f: FE external interface 333 Figure 1: ForCES Architectural Diagram 335 The ForCES protocol domain is found in the Fp Reference Point. The 336 Protocol Element configuration reference points, Fc and Ff also play 337 a role in the booting up of the Forces Protocol. The protocol 338 element configuration is out of scope of the ForCES protocol but is 339 touched on in this document since it is an integral part of the 340 protocol pre-association phase. 342 Figure 2 below shows further breakdown of the Fp interface by example 343 of a MPLS QoS enabled Network Element. 345 ------------------------------------------------- 346 | | | | | | | 347 |OSPF |RIP |BGP |RSVP |LDP |. . . | 348 | | | | | | | 349 ------------------------------------------------- 350 | ForCES Interface | 351 ------------------------------------------------- 352 ^ ^ 353 | | 354 ForCES | |data 355 control | |packets 356 messages| |(e.g., routing packets) 357 | | 358 v v 359 ------------------------------------------------- 360 | ForCES Interface | 361 ------------------------------------------------- 362 | | | | | | | 363 |LPM Fwd|Meter |Shaper |MPLS |Classi-|. . . | 364 | | | | |fier | | 365 ------------------------------------------------- 367 Figure 2: Examples of CE and FE functions 369 The ForCES Interface shown in Figure 2 constitutes two pieces: the PL 370 and TML layer. 372 This is depicted in Figure 3 below. 374 +------------------------------------------------ 375 | CE PL layer | 376 +------------------------------------------------ 377 | CE TML layer | 378 +------------------------------------------------ 379 ^ 380 | 381 ForCES | (i.e Forces data + control 382 PL | packets ) 383 messages | 384 over | 385 specific | 386 TML | 387 encaps | 388 and | 389 transport | 390 | 391 v 392 +------------------------------------------------ 393 | FE TML layer | 394 +------------------------------------------------ 395 | FE PL layer | 396 +------------------------------------------------ 398 Figure 3: ForCES Interface 400 The PL layer is in fact the ForCES protocol. Its semantics and 401 message layout are defined in this document. The TML Layer is 402 necessary to connect two ForCES PL layers as shown in Figure 3 above. 403 The TML is out of scope for this document but is within scope of 404 ForCES. This document defines requirements the PL needs the TML to 405 meet. 407 Both the PL and the TML layers are standardized by the IETF. While 408 only one PL layer is defined, different TMLs are expected to be 409 standardized. To interoperate the TML layer at the CE and FE are 410 expected to conform to the same definition. 412 On transmit, the PL layer delivers its messages to the TML layer. 413 The TML layer delivers the message to the destination TML layer(s). 414 On receive, the TML delivers the message to its destination PL 415 layer(s). 417 3.1.1 The PL layer 419 The PL is common to all implementations of ForCES and is standardized 420 by the IETF as defined in this document. The PL layer is responsible 421 for associating an FE or CE to an NE. It is also responsible for 422 tearing down such associations. An FE uses the PL layer to throw 423 various subscribed-to events to the CE PL layer as well as respond to 424 various status requests issued from the CE PL. The CE configures 425 both the FE and associated LFBs attributes using the PL layer. In 426 addition the CE may send various requests to the FE to activate or 427 deactivate it, reconfigure its HA parametrization, subscribe to 428 specific events etc. More details in Section 6. 430 3.1.2 The TML layer 432 The TML layer is essentially responsible for transport of the PL 433 layer messages. The TML is where the issues of how to achieve 434 transport level reliability, congestion control, multicast, ordering, 435 etc are handled. It is expected more than one TML will be 436 standardized. The different TMLs each could implement things 437 differently based on capabilities of underlying media and transport. 438 However, since each TML is standardized, interoperability is 439 guaranteed as long as both endpoints support the same TML. All 440 ForCES Protocol Layer implementations should be portable across all 441 TMLs, because all TMLs have the same top edge semantics as defined in 442 this document. 444 3.1.3 The FEM/CEM Interface 446 The FEM and CEM components, although valuable in the setup and 447 configurations of both the PL and TML layers, are out of scope of the 448 ForCES protocol. The best way to think of them are as 449 configurations/parameterizations for the PL and TML before they 450 become active (or even at runtime based on implementation). In the 451 simplest case, the FE or CE read a static configuration file which 452 they use as the FEM/CEM interface. RFC 3746 has a lot more detailed 453 descriptions on how the FEM and CEM could be used. We discuss the 454 pre-association phase where the CEM and FEM play briefly in section 455 Section 3.2.1. 457 An example of typical things FEM/CEM would configure would be TML 458 specific parameterizations such as: 459 a. how the TML connection should happen (example what IP addresses 460 to use, transport modes etc); 461 b. the ID for the FE or CE would also be issued at this point. 462 c. Security parameterization such as keys etc. 463 d. Connection association parameters 465 Example "send up to 3 association messages each 1 second apart" Vs " 466 send up to 4 association messages with increasing exponential 467 timeout". 469 3.2 ForCES Protocol Phases 471 ForCES, in relation to NEs, involves two phases: the Pre-Association 472 phase where configuration/initialization/bootup of the TML and PL 473 layer happens, and the association phase where the ForCES protocol 474 operates. 476 3.2.1 Pre-association 478 The ForCES interface is configured during the pre-association phase. 479 In a simple setup, the configuration is static and is read from a 480 saved config file. All the parameters for the association phase are 481 well known after the pre-association phase is complete. A protocol 482 such as DHCP may be used to retrieve the config parameters instead of 483 reading them from a static config file. Note, this will still be 484 considered static pre-association. Dynamic configuration may also 485 happen using the Fc, Ff and Fl reference points. Vendors may use 486 their own proprietary service discovery protocol to pass the 487 parameters. 489 the following are scenarios reproduced from the Framework Document 490 to show a pre-association example. 492 <----Ff ref pt---> <--Fc ref pt-------> 493 FE Manager FE CE Manager CE 494 | | | | 495 | | | | 496 (security exchange) (security exchange) 497 1|<------------>| authentication 1|<----------->|authentication 498 | | | | 499 (FE ID, attributes) (CE ID, attributes) 500 2|<-------------| request 2|<------------|request 501 | | | | 502 3|------------->| response 3|------------>|response 503 (corresponding CE ID) (corresponding FE ID) 504 | | | | 505 | | | | 507 Figure 4: Examples of a message exchange over the Ff and Fc reference 508 points 510 <-----------Fl ref pt--------------> | 512 FE Manager FE CE Manager CE 513 | | | | 514 | | | | 515 (security exchange) | | 516 1|<------------------------------>| | 517 | | | | 518 (a list of CEs and their attributes) | 519 2|<-------------------------------| | 520 | | | | 521 (a list of FEs and their attributes) | 522 3|------------------------------->| | 523 | | | | 524 | | | | 526 Figure 5: An example of a message exchange over the Fl reference 527 point 529 Before the transition to the association phase, the FEM will have 530 established contact with the appropriate CEM component. 531 Initialization of the ForCES interface will be completed, and 532 authentication as well as capability discovery may be complete as 533 well. Both the FE and CE would have the necessary information for 534 connecting to each other for configuration, accounting, 535 identification and authentication purposes. Both sides also would 536 have all the necessary protocol parameters such as timers, etc. The 537 Fl reference point may continue to operate during the association 538 phase and may be used to force a disassociation of an FE or CE. 539 Because the pre-association phase is out of scope, these details are 540 not discussed any further in this specification. The reader is 541 referred to the framework document [RFC3746] for more detailed 542 discussion. 544 3.2.2 Post-association 546 In this phase, the FE and CE components communicate with each other 547 using the ForCES protocol (PL over TML) as defined in this document. 548 There are three sub-phases: 549 o Association setup state 550 o Established State 551 o Association teardown state. 553 3.2.2.1 Association setup state 555 The FE attempts to join the NE. The FE may be rejected or accepted. 556 Once granted access into the NE, capabilities exchange happens with 557 the CE querying the FE. Once the CE has the FE capability 558 information, the CE can offer an initial configure (possibly to 559 restore state) and can query certain attributes within either an LFB 560 or the FE itself. 562 More details are provided in the protocol scenarios section. 564 On successful completion of this state, the FE joins the NE and is 565 moved to the Established State. 567 3.2.2.2 Association Established state 569 In this state the FE is continuously updated or queried. The FE may 570 also send asynchronous event notifications to the CE or synchronous 571 heartbeat notifications. This continues until a termination is 572 initiated by either the CE or the FE. 574 Refer to section on protocol scenarios Section 7 for more details. 576 3.3 Protocol Mechanisms 578 Various semantics are exposed to the protocol users via the PL header 579 including: Transaction capabilities, atomicity of transactions, two 580 phase commits, batching/parallelization, High Availability and 581 failover as well as command windows. 583 3.3.1 Of Transactions, Atomicity and 2 Phase Commits 585 A transaction is a sequence of operations that is guaranteed to be 586 atomic in the presence of any failures by the CEs or FEs. Operation 587 in this sense implies the PL operation within the message body TLV. 588 An example of a transaction could be a config PL msg with a sequence 589 of operations: "route-add A B,C:route-del X" (each operation in its 590 own TLV). 592 If a transaction is split across more than one message, then all 593 messages in the the transaction MUST arrive at the destination before 594 they are executed on either the LFB or FE. All operations are 595 executed serially in the order specified by the transaction. If any 596 of the sequence of operations in a transaction fails then the 597 transaction is declared as a failure. This is an all-or-nothing 598 approach and is needed to ensure consistency of a transaction across 599 multiple FEs. 601 A transaction may be atomic within an FE alone or across the NE. In 602 both cases the atomic requirement for a transaction MUST be met. The 603 PL message header exposes the ability to mark a start of transaction 604 and end of transaction using flags. These flags can be used to 605 derive a classical transactional two phase commit[ACID paper ref 606 here]. 608 3.3.2 FE, CE, and FE protocol LFBs 610 Whereas the four key PL messages, Association Setup, Response, and 611 Teardown, as well as Heartbeat, have a specific types assigned mostly 612 for simplicity and monitoring reasons, all other PL messages follow 613 the LFB structure as this provides more flexibility for future 614 enhancements. In addition, this shows how the ForCES protocol itself 615 can be controlled by the very same type of structures (LFBs) it uses 616 to control functions such as IP forwarding, filtering, etc. 618 To achieve this, the following LFBs are used: 619 o FE Protocol LFB 620 o FE LFB 621 o CE LFB 622 These LFBs are detailed in Section 6.1. A short description is 623 provided here: 624 o The FE Protocol LFB is a logical entity in each FE that is used to 625 control the ForCES protocol. The CE operates on this LFB to 626 subscribe or unsubscribe to Heartbeat messages, define the 627 Heartbeat interval, or to discover which ForCES protocol version 628 is supported and which TMLs the FE supports. The FE Protocol LFB 629 also contains the various ForCES ID to be used: unicast IDs and 630 table of the PL multicast IDs the FE must be listening to. [TBD: 631 do we need a CE Protocol LFB?] 632 o The FE LFB (referred to as "FE attributes" in the model draft) 633 should not be confused with the FE Protocol Object. The FE LFB is 634 a logical entity in each FE and contains attributes relative to 635 the FE itself, and not to the operation of the ForCES protocol 636 between the CE and the FE. Such attributes can be FEState (refer 637 to model draft), vendor, etc. The FE LFB contains in particular 638 an table that maps a virtual LFB Instance ID to one or more 639 Instance IDs of LFBs in the FE. 640 o The CE LFB is the counterpart of the FE LFB. The CE LFB is a 641 logical entity in each CE and contains attributes relative to the 642 CE itself, and not to the operation of the ForCES protocol between 643 the CE and the FE. This LFB can be used to convey event 644 notifications from a CE to FEs. Some events may be sent by the CE 645 without prior subscription by the FEs. 647 3.3.3 Scaling by Concurrency 649 It is desirable that the PL layer not become the bottleneck when 650 larger bandwidth pipes become available. To pick a mythical example 651 in today's terms, if a 100Gbps pipe is available and there is 652 sufficient work then the PL layer should be able to take advantage of 653 this and use all of the 100Gbps pipe. Two mechanisms are provided to 654 achieve this. The first one is batching and the second one is a 655 command window. 657 Batching is the ability to send multiple commands (such as config) in 658 one PDU. The size of the batch will be affected by, amongst other 659 things, the path MTU. The commands may be part of the same 660 transaction or part of unrelated transactions that are independent of 661 each other. 663 Command windowing allows for pipelining of independent transactions 664 which do not affect each other. Each independent transaction could 665 consist of one or more batches. 667 3.3.3.1 Batching 669 There are several batching levels at different protocol hierarchies. 670 o multiple PL PDUs can be aggregated under one TML message 671 o multiple LFB classes and instances can be addressed within one PL 672 PDU 673 o Multiple operations can be addressed to a single LFB class and 674 instance 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 the following security services and describe how 695 they 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, the circumstances under which notification is sent 702 to the PL to notify it of congestion must be defined. 703 4. Uni/multi/broadcast addressing/delivery if any 704 If there is any mapping between PL and TML level 705 Uni/Multi/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 define how. 710 6. HA decisions 711 It is expected that availability of transport links is the TML's 712 responsibility. However, on config basis, the PL layer may wish 713 to participate in link failover schemes and therefore the TML 714 must support 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 configured 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. 762 Version (4 bit): 763 Version number. Current version is 1. 764 rsvd (4 bit): 765 Unused at this point. A receiver should not interpret this 766 field. 767 Command (8 bits): 768 Commands are defined in Section 6. 769 Source ID (32 bit): 770 Dest ID (32 bit): 771 * Each of the source and Dest IDs are 32 bit IDs which 772 recognize the termination points. Ideas discussed so far are 773 desire to recognize if ID belongs to FE or CE by inspection. 774 Suggestions for achieving this involves partitioning of the 775 ID allocation. Another alternative maybe to use flags to 776 indicate direction (this avoids partition). 777 * IDs will allow multi/broad/unicast 778 * Addressing 779 a. As ForCES may run between multiple CEs and FEs and over 780 different protocols such as IPv4 and IPv6, or directly 781 over Ethernet or other switching-fabric interconnects, it 782 is necessary to create an addressing scheme for ForCES 783 entities. Mappings to the underlying TML-level 784 addressing can then be defined as appropriate. 785 b. Fundamentally, unique IDs are assigned to CEs and FEs. A 786 split address space is used to distinguish FEs from CEs. 787 Even though we can assume that in a large NE there are 788 typically two or more orders of magnitude more FEs than 789 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) 855 'SuccessACK'(01) 856 'UnsuccessACK'(10) 857 'ACKAll' (11) 858 - Priority (3 bits) 859 TBD 860 - Throttle flag 861 - Batch (2 bits) 862 - Atomicity (1 or 2 bits) 864 Editorial Note: There are several open issues, listed below, in the 865 header which still need to be settled: 867 1. Parallelization of PL Windowing/subsequence 868 Someone to look into ISCSI 869 2. events and replies and relation to peer to peer 870 vs master slave 871 3. We need to discuss whether some of the Flags 872 such as those for Atomicity, Batching are needed 873 in the common header or only belong to the 874 Config message. 876 6. Protocol Messages 878 The general structure of most messages is as follows (in BNF format): 880 PL level PDU := MAINHDR+ 881 LFBselect := LFBCLASSID LFBInstance + 882 OPER := ]*>+ 884 o MAINHDR defines msg type, Target FE/CE ID etc. The MAINHDR also 885 defines the content. As an example the content of a "config" 886 message would be different from an "association" message. 887 o LFBCLASSID is a 32 bit unique identifier per LFB class defined at 888 class creation time. 889 o LFBInstance is a 32 bit unique instance identifier of an LFB class 890 o OPERATION is one of {ADD,DEL,etc.} depending on the message type 891 o path-data identifies the exact element targeted. It may have zero 892 or more data values associated. 894 In summary this approach has the following characteristic: 895 o there can be one or more LFB Class + InstanceId combo targeted in 896 a message (batch) 897 o There can one or more operation on an addressed LFB 898 classid+instanceid combo(batch) 899 o There can be one or more path targets per operation (batch) 900 o Paths may have zero or more data values associated (flexibility 901 and operation specific) 903 It should be noted that the above is optimized for the case of a a 904 single classid+instance targeting. To target multiple instances 905 within the same class, multiple LFBselect are needed. 907 6.1 Core ForCES LFBs 909 There are three LFBs that are used to control the operation of the 910 ForCES protocol and to interact with FEs and CEs: 911 FE protocol LFB 912 FE LFB 913 CE LFB 915 Although these LFBs have the same form and interface as other LFBs, 916 they are special in many respects: they have fixed well-known LFB 917 Class and Instance IDs. They are statically defined (no dynamic 918 instantiation allowed) and their status cannot be changed by the 919 protocol: any operation to change the state of such LFBs (for 920 instance, in order to disable the LFB) must result in an error. 921 Moreover, these LFBs must exist before the first ForCES message can 922 be sent or received. All attributes in these LFBs must have 923 pre-defined default values. Finally, these LFBs do not have input or 924 output ports and do not integrate into the intra-FE LFB topology. 926 6.1.1 FE Protocol LFB 928 The FE Protocol LFB is a logical entity in each FE that is used to 929 control the ForCES protocol. The FE Protocol LFB Class ID is 930 assigned the value 0x1. The FE LFB Instance ID is assigned the value 931 0x1. There must always be one and only one instance of the FE 932 Protocol LFB in an FE. The values of the attributes in the FE 933 Protocol LFB have pre-defined default values that are specified here. 934 Unless explicit changes are made to these values using Config 935 messages from the CE, these default values MUST be used for the 936 operation of the protocol. 938 The FE Protocol LFB consists of the following elements: 939 o FE Protocol events that can be subscribed/unsubscribed: 940 * FE heartbeat 941 * FE TML events (TBD) 942 o FE Protocol capabilities (read-only): 943 * Supported ForCES protocol version(s) by the FE 944 * Supported ForCES FE model(s) by the FE 945 * Some TML capability description(s) 946 o FE Protocol attributes (can be read and set): 947 * Current version of the ForCES protocol 948 * Current version of the FE model 949 * FE unicast ID 950 * FE multicast ID(s) (list) 951 * Association Expiry Timer 952 * Heartbeat Interval 953 * Primary CE 954 * FE failover and restart policy 955 * CE failover and restart policy 956 Note: Is there a difference between the CE and FE failover 957 policies? 958 TBD: Define default values for each attribute where 959 applicable. 961 6.1.2 FE LFB 963 The FE LFB is a logical entity in each FE and contains attributes 964 relative to the FE itself, and not to the operation of the ForCES 965 protocol. The FE LFB Class ID is assigned the value 0x2. The FE LFB 966 Instance ID is assigned the value 0x1. There must always be one and 967 only one instance of the FE LFB in an FE. 969 The FE LFB consists of the following elements: 971 FE Events: 972 * FEAllEvents: subscribing to this corresponds to subscribing to 973 all events below 974 * FEStatusChange: events that signal FE Status: 975 + Up 976 + Down 977 + Active 978 + Inactive 979 + Failover 980 * FE DoS alert 981 * FE capability change 982 FE attributes: 983 * FEStatus: to set the FE mode as: 984 + Active 985 + Inactive 986 + Shutdown 987 Note: This replaces the State Maintenance messages 988 * FELFBInstancelist 989 * FENeighborList 990 * MIID table: a list of virtual LFB Instance IDs that map to a 991 list of Instance IDs of LFBs in that FE 992 * FE Behavior Exp. Timer 993 * HA Mode 994 * FE DoS protection policy 995 * FEPrivateData: Proprietary info such as name, vendor, model. 996 Note: The attributes below were previously under Query 997 message. 998 * Inter-FE topology Intra-FE topology 1000 6.1.3 CE LFB 1002 The CE LFB is a logical entity in each CE and contains attributes 1003 relative to the CE itself, and not to the operation of the ForCES 1004 protocol. 1006 The CE LFB consists of the following elements: 1007 CE Events: 1008 * CEAllEvents: subscribing to this corresponds to subscribing to 1009 all events listed below. 1010 Note: Do we want to allow an FE to explicitly subscribe to CE 1011 events? 1012 * CEStatusChange: events that signal CE 1013 Up/Down/Active/Inactive/Failover. 1014 Note: Such events do not necessarily need to be subscribed to, 1015 they can fire even without subscription and be sent to 1016 the FE 1018 Note: TBD: what else do we need in the CE LFB? 1020 6.2 Association Messages 1022 The ForCES Association messages are used to establish and teardown 1023 associations between FEs and CEs. 1025 6.2.1 Association Setup Message 1027 This message is sent by the FE to the CE to setup a ForCES 1028 association between them. This message could also be used by CEs to 1029 join a ForCES NE, however CE-to-CE communication is not covered by 1030 this protocol. 1032 Message transfer direction: 1033 FE to CE 1034 Message Header: 1035 The Message Type in the header is set MessageType= 'Association 1036 Setup'. The ACK flag in the header is ignored, because the setup 1037 message will always expect to get a response from the message 1038 receiver (CE) whether the setup is successful or not. The Src ID 1039 (FE ID) may be set to O in the header which means that the FE 1040 would like the CE to assign a FE ID for the FE in the setup 1041 response message. 1042 Message body: 1043 The setup message body consists of LFBSelect & FE Name TLV, the 1044 format of which is as follows: 1046 main hdr (eg type = Association setup) 1047 | 1048 | 1049 +--- T = LFBselect 1050 | | 1051 | +-- LFBCLASSID = FE object 1052 | | 1053 | | 1054 | +-- LFBInstance = 0x1 1055 | 1056 +--- T = Operation = SHOW 1057 | 1058 +-- FE NAME 1060 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 1062 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1063 | Type = LFB select | Length | 1064 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1065 | LFB Class ID = FE Object | 1066 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1067 | LFB Instance ID | 1068 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1069 | Type = operation Show | Length | 1070 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1071 | FE Name string | 1072 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1073 | | 1074 ~ FE Object LFB (including HBI, etc) ~ 1075 | | 1076 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1078 Figure 9 1080 Type (16 bits): 1081 LFB Select 1082 Length (16 bits): 1083 Length of the TLV including the T and L fields, in bytes. 1084 FE Object LFB: 1085 This contains the FE parameters e.g. HBI will be exchanged with 1086 the CE using this LFB. 1087 FE Name String: 1088 This is a string which contains the FE name (part of FE Object 1089 LFB). 1091 Editorial Note: In certain situations (such as use of multicast 1092 IDs), it might not be possible to make use of the 1093 procedure described above for the FE to 1094 dynamically obtain an ID from the CE. Such 1095 situations need to be identified. 1097 6.2.2 Association Setup Response Message 1099 This message is sent by the CE to the FE in response to the Setup 1100 message. It indicates to the FE whether the setup is successful or 1101 not, i.e. whether an association is established. 1103 Message transfer direction: 1104 CE to FE 1105 Message Header: 1106 The Message Type in the header is set MessageType= 'Setup 1107 Response'. The ACK flag in the header is always ignored, because 1108 the setup response message will never expect to get any more 1109 response from the message receiver (FE). The Dst ID in the 1110 header will be set to some FE ID value assigned by the CE if the 1111 FE had requested that in the setup message (by SrcID = 0). 1112 Message body: 1113 The setup response message body consists of LFBSelect & Result 1114 TLV, the format of which is as follows: 1116 main hdr (eg type = Association setup response) 1117 | 1118 | 1119 +--- T = LFBselect 1120 | | 1121 | +-- LFBCLASSID = FE object 1122 | | 1123 | | 1124 | +-- LFBInstance = 0x1 1125 | 1126 +--- T = FEResult 1127 | 1128 +-- resultvalue 1130 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 1132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1133 | Type = LFB select | Length | 1134 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1135 | LFB Class ID = FE Object | 1136 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1137 | LFB Instance ID | 1138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1139 | Type = operation Show | Length | 1140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1141 | | 1142 ~ FE Object LFB (optional) ~ 1143 | | 1144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1145 | Type = Result | Length | 1146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1147 | Result | Reserved | 1148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1150 Figure 10 1152 Type (16 bits): 1153 LFB Select 1154 Length (16 bits): 1155 Length of the TLV including the T and L fields, in bytes. 1156 FE Object LFB: 1157 The FE parameters e.g. HBI may be exchanged using this LFB. 1158 Result (16 bits): 1159 This indicates whether the setup msg was successful or whether 1160 the FE request was rejected by the CE. 1162 6.2.3 Association Teardown Message 1164 This message can be sent by the FE or CE to any ForCES element to end 1165 its ForCES association with that element. 1167 Message transfer direction: 1168 CE to FE, or FE to CE (or CE to CE) 1169 Message Header: 1170 The Message Type in the header is set MessageType= "Asso. 1171 Teardown". The ACK flag in the header is always ignored, because 1172 the teardown message will never expect to get any response from 1173 the message receiver. 1174 Message body: 1175 The association teardown message body consists of LFBSelect & 1176 FEReason TLV, the format of which is as follows: 1178 main hdr (eg type = Association tear) 1179 | 1180 | 1181 +--- T = LFBselect 1182 | | 1183 | +-- LFBCLASSID = FE object 1184 | | 1185 | | 1186 | +-- LFBInstance = 0x1 1187 | 1188 +--- T = FEReason 1189 | 1190 +-- "myreason" 1192 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 1194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1195 | Type = LFB select | Length | 1196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1197 | LFB Class ID = FE Object | 1198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1199 | LFB Instance ID | 1200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1201 | Type = T.reason | Length | 1202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1203 | Reason | 1204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1205 Figure 11 1207 Type (16 bits): 1208 LFB Select 1209 Length (16 bits): 1210 Length of the TLV including the T and L fields, in bytes. 1211 T.reason (32 bits): 1212 This indicates the reason why the association is being 1213 terminated. 1215 6.3 Configuration Messages 1217 The ForCES Configuration messages are used by the CEs to configure 1218 the FEs in a ForCES NE and report the results back to the CE. 1220 6.3.1 Config Message 1222 This message is sent by the CE to the FE to configure FE or LFB 1223 attributes. This message is also used by the CE to 1224 subscribe/unsubscribe to FE and LFB events. 1226 Message transfer direction: 1227 CE to FE 1228 Message Header: 1229 The Message Type in the header is set MessageType= 'Config'. The 1230 ACK flag in the header is can be used by the CE to turn off any 1231 response from the FE. The default behavior is to turn on the ACK 1232 to get the config response from the FE. 1233 Message body: 1234 The Config message body consists of one or more TLVs, the format 1235 of a single (LFB) TLV is as follows: 1237 main hdr (eg type = config) 1238 | 1239 | 1240 +--- T = LFBselect 1241 | | 1242 | +-- LFBCLASSID = target LFB class 1243 | | 1244 | | 1245 | +-- LFBInstance = target LFB instance 1246 | | 1247 | | 1248 | +-- T = operation { ADD, DEL, etc} 1249 | | | 1250 | | +-- // one or more path targets 1251 | | // under discussion 1252 | | 1253 | +-- T = operation { ADD, DEL, etc} 1254 | | | 1255 | | +-- // one or more path targets 1256 | | // under discussion 1257 | | 1258 | +-- T = operation { ADD, DEL, etc} 1259 | | | 1260 | | +-- // one or more path targets 1261 | | // under discussion 1262 | | 1264 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 1265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1266 | Type = LFB select | Length | 1267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1268 | LFB Class ID | 1269 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1270 | LFB Instance ID | 1271 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1272 | Type = Operations (ADD) | Length | 1273 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1274 | | 1275 ~ Config data ~ 1276 | | 1277 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1278 | Type = Operations (DEL) | Length | 1279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1280 | | 1281 ~ Config data ~ 1282 | | 1283 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1285 Figure 12 1287 Type (16 bits): 1288 LFB Select. 1289 Length (16 bits): 1290 Length of the TLV including the T and L fields, in bytes. 1291 LFB Class ID (16 bits): 1292 This field uniquely recognizes the LFB class/type. 1293 LFB Instance ID (16 bits): 1294 This field uniquely identifies the LFB instance. 1295 Type (16 bits): 1296 The operations include, ADD, DEL, UPDATE/REPLACE, DEL ALL, EVENT 1297 SUBSCRIBE, EVENT UNSUBSCRIBE, PACKET SUBSCRIBE, PACKET 1298 UNSUBSCRIBE, CANCEL. 1300 Length (16 bits): 1301 Length of the TLV including the T and L fields, in bytes. 1302 Config Data (variable length): 1303 This will carry LFB specific data (, single or Array LFB 1304 specific entries). The config data might itself be of the form 1305 of a TLV. 1306 *Note: FE Activate/Deactivate, Shutdown FE commands for State 1307 Maintenance will be sent using Config messages. 1308 *Note: For Event subscription, the events will be defines by the 1309 individual LFBs. 1311 6.3.2 Config Response Message 1313 This message is sent by the FE to the CE in response to the Config 1314 message. It indicates whether the Config was successful or not on 1315 the FE and also gives a detailed response regarding the configuration 1316 result of each attribute. 1318 Message transfer direction: 1319 FE to CE 1320 Message Header: 1321 The Message Type in the header is set MessageType= 'Config 1322 Response'. The ACK flag in the header is always ignored, because 1323 the config response message will never expect to get any more 1324 response from the message receiver (CE). 1325 Message body: 1326 The Config response message body consists of one or more TLVs, 1327 the format of a single TLV is as follows: 1329 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 1331 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1332 | Type = LFB select | Length | 1333 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1334 | LFB Class ID | 1335 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1336 | LFB Instance ID | 1337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1338 | Type = Operations (ADD) | Length | 1339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1340 | Operation Result | reserved | 1341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1342 | | 1343 ~ Config Result ~ 1344 | | 1345 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1346 | Type = Operations (DEL) | Length | 1347 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1348 | Operation Result | reserved | 1349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1350 | | 1351 ~ Config Result ~ 1352 | | 1353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1355 Figure 13 1357 Type (16 bits): 1358 LFB Select. 1359 Length (16 bits): 1360 Length of the TLV including the T and L fields, in bytes. 1361 LFB Class ID (16 bits): 1362 This field uniquely recognizes the LFB class/type. 1363 LFB Instance ID (16 bits): 1364 This field uniquely identifies the LFB instance. 1365 Type (16 bits): 1366 The operations are same as those defined for Config messages. 1367 Length (16 bits): 1368 Length of the TLV including the T and L fields, in bytes. 1369 Operation Result (16 bits): 1370 This indicates the overall result of the config operation, 1371 whether it was successful or it failed. 1372 Config Result (variable length): 1373 This will carry LFB specific results (single or Array LFB 1374 specific result entries). The config result might itself be of 1375 the form of a TLV. 1377 6.4 Query and Query Response Messages 1379 The ForCES query and query response messages are used for one ForCES 1380 element (CE or FE) to query other ForCES element(s) for various kinds 1381 of information. Current version of ForCES protocol limits the use of 1382 the messages only for CE to query information of FE. 1384 6.4.1 Query Message 1386 As usual, a query message is composed of a common header and a 1387 message body that consists of one or more TLV data format. Detailed 1388 description of the message is as below. 1390 Message transfer direction: 1391 Current version limits the query message transfer direction only 1392 from CE to FE. 1393 Message Header: 1394 The Message Type in the header is set to MessageType= 'Query'. 1395 The ACK flag in the header SHOULD be set 'ACKAll', meaning a full 1396 response for a query message is always expected. If the ACK flag 1397 is set other values, the meaning of the flag will then be 1398 ignored, and a full response will still be returned by message 1399 receiver. 1400 Message body: 1401 The query message body consists of (at least) one or more than 1402 one TLVs that describe entries to be queried. The TLV is called 1403 LFBselect TLV and the data format is as below: 1405 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 1406 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1407 | Type = LFBselect | Length | 1408 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1409 | LFB Class ID | 1410 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1411 | LFB Instance ID | 1412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1413 | Operation TLV | 1414 . . 1415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1416 ~ ... ~ 1417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1418 | Operation TLV | 1419 . . 1420 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1422 Figure 14 1424 Editorial Note: 1425 1. Under discussion is whether there is a need 1426 for explicit multiple LFB insatance 1427 addressing here. One way to realize it is 1428 to define a specific Instance select TLV to 1429 substitute above 'LFB Instance ID' field. 1430 The TLV may have following format: 1432 INSselectTLV := Type Length Value 1433 Type := INSselect 1434 Value := InstanceID (RangeMark | Instance ID)+ 1436 2. An applicable RangeMark is '0xffffffff', the 1437 value of which is the same as Instance 1438 broadcast ID. Because there will be no 1439 broadcast address applied in this place, 1440 there will be no worry of ambiguity here. 1442 Operation TLV: 1443 The Operation TLV for the 'Query' message is formatted as: 1445 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1446 | Type = GET | Length | 1447 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1448 | Path(or Attribute ID?) | 1449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1450 | Query Data | 1451 . . 1452 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1454 Figure 16 1456 Path(or Attribute ID?): 1457 [Under discussion and TBD] 1459 Editorial Note: There is a debate on whether we should use a 1460 'Path' or simply an 'Attribute ID' or a 'Table 1461 ID' here at the protocol layer. A Path is used 1462 for data indexing for a table, while an 1463 'Attribute ID' or a 'Table ID' only specify 1464 which attribute or table to use, leaving table 1465 index to be included in followed data. 1467 Query Data: 1468 [Under discussion and TBD] 1470 To better understand the above PDU format, we can show a tree 1471 structure for the format as below: 1473 main hdr (type = Query) 1474 | 1475 | 1476 +--- T = LFBselect 1477 | | 1478 | +-- LFBCLASSID = target LFB class 1479 | | 1480 | | 1481 | +-- LFBInstance = target LFB instance 1482 | | 1483 | | 1484 | +-- T = operation { GET } 1485 | | | 1486 | | +-- // one or more path targets 1487 | | // under discussion 1488 | +-- T = operation { GET } 1489 | | | 1490 | | +-- // one or more path targets 1491 | | 1493 Figure 17 1495 6.4.2 Query Response Message 1497 When receiving a query message, the receiver should process the 1498 message and come up with a query result. The receiver sends the 1499 query result back to the message sender by use of the Query Response 1500 Message. The query result can be the information being queried if 1501 the query operation is successful, or can also be error codes if the 1502 query operation fails, indicating the reasons for the failure. 1504 A query response message is also composed of a common header and a 1505 message body consists of one or more TLVs describing the query 1506 result. Detailed description of the message is as below. 1508 Message transfer direction: 1509 Current version limits the query response message transfer 1510 direction only from FE to CE. 1512 Message Header: 1513 The Message Type in the header is set to MessageType= 1514 'QueryResponse'. The ACK flag in the header SHOULD be set 1515 'NoACK', meaning no further response for a query response message 1516 is expected. If the ACK flag is set other values, the meaning of 1517 the flag will then be ignored. The Sequence Number in the header 1518 SHOULD keep the same as that of the query message to be 1519 responded, so that the query message sender can keep track of the 1520 responses. 1521 Message body: 1522 The message body for a query response message consists of (at 1523 least) one or more than one TLVs that describe query results for 1524 individual queried entries. The TLV is also called LFBselect 1525 TLV, and has exactly the same data format as query message, 1526 except the Operation TLV inside is different. The order of the 1527 TLV here matches the TLVs in the corresponding Query message, and 1528 the TLV number should keep the same. The Operation TLV here is a 1529 'GET-RESPONSE' TLV and the data is 'Query Response Data', as 1530 below: 1532 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1533 | Type = GET-RESPOSE | Length | 1534 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1535 | Path(or Attribute ID?) | 1536 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1537 | Query Response Data | 1538 . . 1539 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1541 Figure 18 1543 Query Response Data: 1544 [Under discussion and TBD] 1546 6.5 Event Notification and Response Messages 1548 The Event Notification Message is used for one ForCES element to 1549 asynchronously notify one or more other ForCES elements in the same 1550 ForCES NE on just happened events in it. The Event Notification 1551 Response Message is used for the receiver of the Event Notification 1552 Message to acknowledge the reception of the event notification. 1554 Events in current ForCES protocol can be categorized into following 1555 types: 1556 o Events happened in CE 1557 o Events happened in FE 1559 Events can also be categorized into two classes according to whether 1560 they need subscription or not. An event in one ForCES element that 1561 needs to be subscribed will send notifications to other ForCES 1562 elements only when the other elements have subscribed to the element 1563 for the event notification. How to subscribe/unsubscribe for an 1564 event is described in the Configure Message in Section 6.3. An event 1565 that needs not to be subscribed will always send notifications to 1566 other ForCES elements when the event happens. An event definition 1567 made by ForCES protocol, ForCES FE model, or by vendors will state if 1568 the event needs subscription or not. 1570 Editorial Note: There is an argument that it is preferable to have 1571 all events subscribable. 1573 6.5.1 Event Notification Message 1575 As usual, an Event Notification Message is composed of a common 1576 header and a message body that consists of one or more TLV data 1577 format. Detailed description of the message is as below. 1578 Message Transfer Direction: 1579 FE to CE, or CE to FE 1580 Message Header: 1581 The Message Type in the message header is set to 1582 MessageType = 'EventNotification'. The ACK flag in the header can 1583 be set as: ACK flag ='NoACK'|'SuccessAck'|'UnsuccessACK'|'ACKAll'. 1584 Note that the 'Success' here only means the receiver of the 1585 message has successfully received the message. 1586 Message Body: 1587 The message body for an event notification message consists of (at 1588 least) one or more than one TLVs that describe the notified 1589 events. The TLV is defined as follows: 1591 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 1592 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1593 | Type = LFBselect | Length | 1594 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1595 | LFB Class ID | 1596 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1597 | LFB Instance ID | 1598 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1599 | Operation TLV | 1600 . . 1601 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1602 ~ ... ~ 1603 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1604 | Operation TLV | 1605 . . 1606 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1607 Figure 19 1609 Operation TLV: 1610 This is a TLV that describes the event to be notified, as follows: 1612 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1613 | Type = REPORT | Length | 1614 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1615 | Path(or Event ID?) | 1616 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1617 | Event Data | 1618 . . 1619 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1621 Figure 20 1623 Path(or Event ID): 1624 [Under discussion and TBD] 1625 Event Data: 1626 [Under discussion and TBD] 1628 To better understand the above PDU format, we can show a tree 1629 structure for the format as below: 1631 main hdr (type = Event Notification) 1632 | 1633 | 1634 +--- T = LFBselect 1635 | | 1636 | +-- LFBCLASSID = target LFB class 1637 | | 1638 | | 1639 | +-- LFBInstance = target LFB instance 1640 | | 1641 | | 1642 | +-- T = operation { REPORT } 1643 | | | 1644 | | +-- // one or more path targets 1645 | | // under discussion 1646 | +-- T = operation { REPORT } 1647 | | | 1648 | | +-- // one or more path targets 1649 | | 1651 Figure 21 1653 6.5.2 Event Notification Response Message 1655 After sending out an Event Notification Message, the sender may be 1656 interested in ensuring that the message has been received by 1657 receivers, especially when the sender thinks the event notification 1658 is vital for system management. An Event Notification Response 1659 Message is used for this purpose. The ACK flag in the Event 1660 Notification Message header are used to signal if such acknowledge is 1661 requested or not by the sender. 1663 Detailed description of the message is as below: 1664 Message Transfer Direction: 1665 From FE to CE or from CE to FE, just inverse to the direction of 1666 the Event Notification Message that it responses. 1667 Message Header: 1668 The Message Type in the header is set MessageType= 1669 'EventNotificationResponse'. The ACK flag in the header SHOULD be 1670 set 'NoACK', meaning no further response for the message is 1671 expected. If the ACK flag is set other values, the meaning of the 1672 flag will then be ignored. The Sequence Number in the header 1673 SHOULD keep the same as that of the message to be responded, so 1674 that the event notificatin message sender can keep track of the 1675 responses. 1676 Message Body: 1677 The message body for an event notification response message 1678 consists of (at least) one or more than one TLVs that describe the 1679 notified events. The TLV is also called LFBselect TLV, and has 1680 exactly the same data format as Event Notification Message, except 1681 the Operation TLV inside is different. The order of the TLV here 1682 matches the TLVs in the corresponding Event Message, and the TLV 1683 number should keep the same. The Operation TLV here is a 1684 'REPORT-RESPONSE' TLV and the data is 'Event Response Data', as 1685 below: 1687 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1688 | Type = REPORT-RESPONSE | Length | 1689 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1690 | Path(or Event ID?) | 1691 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1692 | Result | Reason | Code | 1693 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1695 Figure 22 1697 Path(or Event ID?): 1698 [Under discussion and TBD] 1699 Result: 1700 This describes the reception result of the event notification 1701 message as below: 1703 Result Value Meaning 1704 'Success' The event has been successfully received. 1705 'Unsuccess' The event has not been successfully received. 1707 Reason, Code: 1708 This describes the reason and possible error code when the message 1709 is not successfully received. Note that only the failure at the 1710 protocol layer rather than the transport layer can be handled 1711 here, that is, if even the header part of the message to be 1712 responded can not be correctly received, the response to the 1713 message will not be able to be generated by the receiver. 1715 Editorial Note: There is a debate on whether the Event 1716 Notification Response Message is necessary or 1717 not. The pro for it is some event notification 1718 senders may be interested in knowing if receivers 1719 have had success/unsuccess receptions of the 1720 events or not. An alternative to generate such 1721 response is for the protocol to define a 1722 universal ACK message so that it can act as 1723 responses for any types of messages as well as 1724 the event notification messages, when the message 1725 senders are interested in knowing whether the 1726 messages have been successfully received or not 1727 (different from the responses for the message 1728 processing results). 1730 6.6 Packet Redirect Message 1732 Packet redirect message is used to transfer data packets between CE 1733 and FE. Usually these data packets are IP packets, though they may 1734 sometimes associated with some metadata generated by other LFBs in 1735 the model, or they may occasionally be other protocol packets, which 1736 usually happen when CE and FE are jointly implementing some 1737 high-touch operations. Packets redirected from FE to CE are the data 1738 packets that come from forwarding plane, and usually are the data 1739 packets that need high-touch operations in CE,or packets for which 1740 the IP destination address is the NE. Packets redirected from CE to 1741 FE are the data packets that come from the CE and are decided by CE 1742 to put into forwarding plane in FE. 1744 Supplying such a redirect path between CE and FE actually leads to a 1745 possibility of this path being DoS attacked. Attackers may 1746 maliciously try to send huge spurious packets that will be redirected 1747 by FE to CE, making the redirect path been congested. ForCES 1748 protocol and the TML layer will jointly supply approaches to prevent 1749 such DoS attack. To define a specific 'Packet Redirect Message' 1750 makes TML and CE able to distinguish the redirect messages from other 1751 ForCES protocol messages. 1753 By properly configuring related LFBs in FE, a packet can also be 1754 mirrored to CE instead of purely redirected to CE, i.e., the packet 1755 is duplicated and one is redirected to CE and the other continues its 1756 way in the LFB topology. 1758 Editorial Note: There are also discussions on how LFBs in FE model 1759 that are related to packet redirect operations 1760 should be defined. Although it is out of the scope 1761 of forces protocol, how to define the LFBs affect 1762 the Packet Redirect Message described here. Because 1763 currently it is still in progress in FE model on how 1764 to define such LFBs, we try to post some thoughts on 1765 this here for discussion. They will be removed 1766 later along with the progress of the FE model work. 1768 Thought 1: To define LFBs called 'RedirectSink' and 1769 'RedirectTap' for packet redirect. 1770 An LFB in FE called 'RedirectSink' is responsible to 1771 collect data packets that need to be redirected to 1772 CE. From the perspective of the FE LFB topology, 1773 the 'RedirectSink' LFB is an LFB with only one input 1774 port and without any output port, and the input port 1775 can then be connected to any other LFB in FE model 1776 by means of a datapath in the forwarding plane. 1777 From the perspective of the ForCES protocol layer, 1778 the 'RedirectSink' LFB will generate the Packet 1779 Redirect Messages when it receives data packets from 1780 forwarding plane. 1782 An LFB in FE called 'RedirectTap' is responsible to 1783 receive data packets that are redirected from CE. 1784 From the perspective of the FE LFB topology, the 1785 'RedirectTap' LFB is an LFB with only one output 1786 port and without any input port, and the output port 1787 can then be connected to any other LFB in FE model 1788 by means of a datapath in the forwarding plane. 1789 From the perspective of ForCES protocol layer, the 1790 'RedirectTap' LFB can receive the Packet Redirect 1791 Messages from CE, and un-encapsulate the data 1792 packets from the message and put them to datapaths 1793 in the forwarding plane. Actually the 'RecirectTap' 1794 LFB acts more like a transcoder that transfers the 1795 ForCES protocol messages to normal data packets in 1796 IP forwarding plane. As a result, if we need to 1797 have redirected packets connected to some LFB (say a 1798 Scheduler) in FE model, we only need to connect the 1799 'RedirectTap LFB to the Scheduler LFB directly via a 1800 datapath as follows: 1802 +-----------------+ +-----------+ 1803 | RedirectTap LFB |------>| | 1804 +-----------------+ | | 1805 | Scheduler | 1806 From other LFB ---->| LFB | 1807 | | 1808 +-----------+ 1810 Figure 24 1812 By use of several 'RedirectSink' LFBs and several 1813 'RedirectTap' LFBs that connect to several different 1814 datapaths in FE forwarding plane, multiple packet 1815 redirect paths between CE and FE can be constructed. 1817 Thought 2: There might be another way a packet could be 1818 redirected: directly by a forwarding path, e.g., by 1819 FPGA/ASIC/NP microcode. In such a case we do not 1820 need to put in a lot of smartness. Probably a link 1821 layer or even network level header is enough. The 1822 receiver demuxes it only based on some protocol type 1823 in the link layer or network transport layer. The 1824 pros for this appraoch is it may provide a fast and 1825 cost-effective path for packet redirect. The cons 1826 for this is it may more or less confuses the Fp 1827 reference point definition in ForCES framework. 1829 We describe the Packet Redirect Message data format in details as 1830 follows: 1831 Message Direction: 1832 CE to FE or FE to CE 1833 Message Header: 1834 The Message Type in the header is set to MessageType= 1835 'PacketRedirect'. The ACK flags in the header SHOULD be set 1836 'NoACK', meaning no response is expected by this message. If the 1837 ACK flag is set other values, the meanings will be ignored. 1839 Message Body: 1840 Consists of one or more TLVs, with every TLV having the following 1841 data format: 1843 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 1844 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1845 | Type = LFBselect | Length | 1846 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1847 | LFB Class ID | 1848 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1849 | LFB Instance ID | 1850 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1851 | Operation TLV | 1852 . . 1853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1854 ~ ... ~ 1855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1856 | Operation TLV | 1857 . . 1858 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1860 Figure 25 1862 LFB class ID: 1863 There are only two possible LFB classes here, the 'RedirectSink' 1864 LFB or the 'RedirectTap' LFB. If the message is from FE to CE, 1865 the LFB class should be 'RedirectSink'. If the message is from CE 1866 to FE, the LFB class should be 'RedirectTap'. 1867 Instance ID: 1868 Instance ID for the 'RedirectSink' LFB or 'RedirectTap' LFB. 1869 Operation TLV: 1870 This is a TLV describing one packet of data to be directed via the 1871 specified LFB above. The order of the data number is also the 1872 order the data packet arrives the redirector LFB, that is, the 1873 Redirected Data #1 should arrive earlier than the Redirected Data 1874 #2 in this redirector LFB. The TLV format is as follows: 1876 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1877 | Type = PAYLOAD | Length | 1878 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1879 | Path(or Sequence Number?) | 1880 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1881 ~ Redirected Data ~ 1882 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 1884 Figure 26 1886 Path(or Sequence Number?): 1887 [Under discussion and TBD] 1888 Type: 1889 [TBD] 1890 Redirected Data: 1891 This field will make a detailed description of the data to be 1892 redirected as well as the data itself. The encoding of the 1893 description is based on the ForCES FE model if the redirector LFB 1894 is defined by FE model, or based on vendor specifications if the 1895 redirector LFB is defined by vendors. The description will 1896 usually include the name (or the name ID) of the redirected packet 1897 data (such as 'IPv4 Packet', 'IPv6 Packet'), and the packet data 1898 itself. It may also include some metadata (metadata name (or name 1899 ID) and its value)associated with the redirected data packet. 1901 6.7 Heartbeat Message 1903 The Heartbeat (HB) Message is used for one ForCES element (FE or CE) 1904 to asynchronously notify one or more other ForCES elements in the 1905 same ForCES NE on its liveness. 1907 A Heartbeat Message is sent by a ForCES element periodically. The 1908 time interval to send the message is set by the Association Setup 1909 Message described in Section 6.1.1. A little different from other 1910 protocol messages, a Heartbeat message is only composed of a common 1911 header, withe the message body left empty. Detailed description of 1912 the message is as below. 1913 Message Transfer Direction: 1914 FE to CE, or CE to FE 1915 Message Header: 1916 The Message Type in the message header is set to MessageType = 1917 'Heartbeat'. The ACK flag in the header SHOULD be set to 1918 'NoACK', meaning no response from receiver(s) is expected by the 1919 message sender. Other values of the ACK flag will always be 1920 ignored by the message receiver. 1921 Message Body: 1922 The message body is empty for the Heartbeat Message. 1924 6.8 Operation Summary 1926 The following tables summarize the operations and their applicabiity 1927 to the messages. 1929 No Operations for the following messages: 1930 Assoc-Setup 1931 Assoc-Setup-Resp 1932 Assoc-Teardown 1933 Heartbeat 1935 +-------------------+-------+------------+--------+-------------+ 1936 | Operation | Query | Query-Resp | Config | config-Resp | 1937 +-------------------+-------+------------+--------+-------------+ 1938 | Set | | | X | X | 1939 | | | | | | 1940 | Delete | | | X | X | 1941 | | | | | | 1942 | Update | | | X | X | 1943 | | | | | | 1944 | Get | X | X | | | 1945 | | | | | | 1946 | Event subscribe | | | X | X | 1947 | | | | | | 1948 | Event unsubscribe | | | X | X | 1949 +-------------------+-------+------------+--------+-------------+ 1951 +-----------+--------------+-------------+------------------+ 1952 | Operation | Packet-Redir | Event-Notif | Event-Notif-Resp | 1953 +-----------+--------------+-------------+------------------+ 1954 | Payload | X | | | 1955 | | | | | 1956 | Event | | X | X | 1957 +-----------+--------------+-------------+------------------+ 1959 7. Protocol Scenarios 1961 7.1 Association Setup state 1963 The associations among CEs and FEs are initiated via Association 1964 setup message from the FE. If a setup request is granted by the CE, 1965 a successful setup response message is sent to the FE. If CEs and 1966 FEs are operating in an insecure environment then the security 1967 association have to be established between them before any 1968 association messages can be exchanged. The TML will take care of 1969 establishing any security associations. 1971 This is followed by capability query, topology query. When the FE is 1972 ready to start forwarding data traffic, it sends a FE UP Event 1973 message to the CE. The CE responds with a FE ACTIVATE State 1974 Maintenance message to ask the FE to go active and start forwarding 1975 data traffic. At this point the association establishment is 1976 complete. These sequences of messages are illustrated in the Figure 1977 below. 1979 FE PL CE PL 1981 | | 1982 | Asso Setup Req | 1983 |---------------------->| 1984 | | 1985 | Asso Setup Resp | 1986 |<----------------------| 1987 | | 1988 | Capability Query | 1989 |<----------------------| 1990 | | 1991 | Query Resp | 1992 |---------------------->| 1993 | | 1994 | Topo Query | 1995 |<----------------------| 1996 | | 1997 | Topo Query Resp | 1998 |---------------------->| 1999 | | 2000 | FE UP Event | 2001 |---------------------->| 2002 | | 2003 | Config-Activate FE | 2004 |<----------------------| 2005 | | 2007 Figure 27: Message exchange between CE and FE to establish an NE 2008 association 2010 On successful completion of this state, the FE joins the NE and is 2011 moved to the Established State or Steady state. 2013 7.2 Association Established state or Steady State 2015 In this state the FE is continously updated or queried. The FE may 2016 also send asynchronous event notifications to the CE or synchronous 2017 heartbeat messages. This continues until a termination (or 2018 deactivation) is initiated by either the CE or FE. Figure below 2019 helps illustrate this state. 2021 FE PL CE PL 2023 | | 2024 | Heart Beat | 2025 |<----------------------| 2026 | | 2027 | Heart Beat | 2028 |---------------------->| 2029 | | 2030 | Config-Subscribe Ev | 2031 |<----------------------| 2032 | | 2033 | Config Resp | 2034 |---------------------->| 2035 | | 2036 | Config-Add LFB Attr | 2037 |<----------------------| 2038 | | 2039 | Config Resp | 2040 |---------------------->| 2041 | | 2042 | Query LFB Stats | 2043 |<----------------------| 2044 | | 2045 | Query Resp | 2046 |---------------------->| 2047 | | 2048 | FE Event Report | 2049 |---------------------->| 2050 | | 2051 | Config-Del LFB Attr | 2052 |<----------------------| 2053 | | 2054 | Config Resp | 2055 |---------------------->| 2056 | | 2057 | Packet Redirect | 2058 |---------------------->| 2059 | | 2060 | Heart Beat | 2061 |<----------------------| 2062 . . 2063 . . 2064 | | 2065 | Config-Activate FE | 2066 |<----------------------| 2067 | | 2069 Figure 28: Message exchange between CE and FE during steady-state 2070 communication 2072 Note that the sequence of messages shown in the figure serve only as 2073 examples and the messages exchange sequences could be different from 2074 what is shown in the figure. Also, note that the protocol scenarios 2075 described in this section do not include all the different message 2076 exchanges which would take place during failover. That is described 2077 in the HA section 8. 2079 8. High Availability Support 2081 The ForCES protocol provides mechanisms for CE redundancy and 2082 failover, in order to support High Availability as defined in 2083 [RFC3654]. FE redundancy and FE to FE interaction is currently out 2084 of scope of this draft. There can be multiple redundant CEs and FEs 2085 in a ForCES NE. However, at any time there can only be one Primary 2086 CE controlling the FEs and there can be multiple secondary CEs. The 2087 FE and the CE PL are aware of the primary and secondary CEs. This 2088 information (primary, secondary CEs) is configured in the FE, CE PLs 2089 during pre-association by FEM, CEM respectively. Only the primary CE 2090 sends Control messages to the FEs. The FE may send its event 2091 reports, redirection packets to only the Primary CE (Report Primary 2092 Mode) or it may send these to both primary and secondary CEs (Report 2093 All Mode). (The latter helps with keeping state between CEs 2094 synchronized, although it does not guarantee synchronization.) This 2095 behavior or HA Modes are configured during Association setup phase 2096 but can be changed by the CE anytime during protocol operation. A 2097 CE-to-CE synchronization protocol will be needed in most cases to 2098 support fast failover, however this will not be defined by the ForCES 2099 protocol. 2101 During a communication failure between the FE and CE (which is caused 2102 due to CE or link reasons, i.e. not FE related), the TML on the FE 2103 will trigger the FE PL regarding this failure. This can also be 2104 detected using the HB messages between FEs and CEs. The FE PL will 2105 send a message (Event Report) to the Secondary CEs to indicate this 2106 failure or the CE PL will detect this and one of the Secondary CEs 2107 takes over as the primary CE for the FE. During this phase, if the 2108 original primary CE comes alive and starts sending any commands to 2109 the FE, the FE should ignore those messages and send an Event to all 2110 CEs indicating its change in Primary CE. Thus the FE only has one 2111 primary CE at a time. 2113 An explicit message (Config message- Move command) from the primary 2114 CE, can also be used to change the Primary CE for an FE during normal 2115 protocol operation. In order to support fast failover, the FE will 2116 establish association (setup msg) as well as complete the capability 2117 exchange with the Primary as well as all the Secondary CEs (in all 2118 scenarios/modes). 2120 These two scenarios (Report All, Report Primary) have been 2121 illustrated in the figures below. 2123 FE CE Primary CE Secondary 2124 | | | 2125 | Asso Estb,Caps exchg | | 2126 1 |<--------------------->| | 2127 | | | 2128 | Asso Estb,Caps|exchange | 2129 2 |<----------------------|------------------->| 2130 | | | 2131 | All msgs | | 2132 3 |<--------------------->| | 2133 | | | 2134 | packet redirection,|events, HBs | 2135 4 |-----------------------|------------------->| 2136 | | | 2137 | FAILURE | 2138 | | 2139 | Event Report (pri CE down) | 2140 5 |------------------------------------------->| 2141 | | 2142 | All Msgs | 2143 6 |------------------------------------------->| 2145 Figure 29: CE Failover for Report All mode 2146 FE CE Primary CE Secondary 2147 | | | 2148 | Asso Estb,Caps exchg | | 2149 1 |<--------------------->| | 2150 | | | 2151 | Asso Estb,Caps|exchange | 2152 2 |<----------------------|------------------->| 2153 | | | 2154 | All msgs | | 2155 3 |<--------------------->| | 2156 | | | 2157 | (HeartBeats| only) | 2158 4 |-----------------------|------------------->| 2159 | | | 2160 | FAILURE | 2161 | | 2162 | Event Report (pri CE down) | 2163 5 |------------------------------------------->| 2164 | | 2165 | All Msgs | 2166 6 |------------------------------------------->| 2168 Figure 30: CE Failover for Report Primary Mode 2170 8.1 Responsibilities for HA 2172 TML level - Transport level: 2173 1. The TML controls logical connection availability and failover. 2174 2. The TML also controls peer HA managements. 2176 At this level, control of all lower layers, for example transport 2177 level (such as IP addresses, MAC addresses etc) and associated links 2178 going down are the role of the TML. 2180 PL Level: 2181 All the other functionality including configuring the HA behavior 2182 during setup, the CEIDs are used to identify primary, secondary CEs, 2183 protocol Messages used to report CE failure (Event Report), Heartbeat 2184 messages used to detect association failure, messages to change 2185 primary CE (config - move), and other HA related operations described 2186 before are the PL responsibility. 2188 To put the two together, if a path to a primary CE is down, the TML 2189 would take care of failing over to a backup path, if one is 2190 available. If the CE is totally unreachable then the PL would be 2191 informed and it will take the appropriate actions described before. 2193 9. Security Considerations 2195 ForCES architecture identified several [Reference Arch] levels of 2196 security. ForCES PL uses security services provided by the ForCES 2197 TML layer. TML layer provides security services such as endpoint 2198 authentication service, message authentication service and 2199 confidentiality service. Endpoint authentication service is invoked 2200 at the time of pre-association connection establishment phase and 2201 message authentication is performed whenever FE or CE receives a 2202 packet from its peer. 2204 Following are the general security mechanism that needs to be in 2205 place for ForCES PL layer. 2206 o Security mechanism are session controlled that is once the 2207 security is turned ON depending upon the chosen security level (No 2208 Security, Authentication only, Confidentiality), it will be in 2209 effect for the entire duration of the session. 2210 o Operator should configure the same security policies for both 2211 primary and backup FE's and CE's (if available). This will ensure 2212 uniform operations, and to avoid unnecessary complexity in policy 2213 configuration. 2214 o ForCES PL endpoints SHOULD pre-established connections with both 2215 primary and backup CE's. This will reduce the security messages 2216 and enable rapid switchover operations for HA. 2218 9.1 No Security 2220 When No security is chosen for ForCES protocol communication, both 2221 endpoint authentication and message authentication service needs be 2222 performed by ForCES PL layer. Both these mechanism are weak and does 2223 not involve cryptographic operation. Operator can choose "No 2224 security" level when the ForCES protocol endpoints are within an 2225 single box. 2227 In order to have interoperable and uniform implementation across 2228 various security levels, each CE and FE endpoint MUST implement this 2229 level. The operations that are being performed for "No security" 2230 level is required even if lower TML security services are being used. 2232 9.1.1 Endpoint Authentication 2234 Each CE and FE PL layer maintain set of associations list as part of 2235 configuration. This is done via CEM and FEM interfaces. FE MUST 2236 connect to only those CE's that are configured via FEM similarly CE 2237 should accept the connection and establish associations for the FE's 2238 which are configured via CEM. CE should validate the FE identifier 2239 before accepting the connection during the pre-association phase. 2241 9.1.2 Message authentication 2243 When CE or FE generates initiates a message, the receiving endpoint 2244 MUST validate the initiator of the message by checking the common 2245 header CE or FE identifiers. This will ensure proper protocol 2246 functioning. We recommend this extra step processing even if the 2247 underlying TLM layer security services. 2249 9.2 ForCES PL and TML security service 2251 This section is applicable if operator wishes to use the TML security 2252 services. ForCES TML layer MUST support one or more security service 2253 such as endpoint authentication service, message authentication 2254 service, confidentiality service as part of TML security layer 2255 functions. It is the responsibility of the operator to select 2256 appropriate security service and configure security policies 2257 accordingly. The details of such configuration is outside the scope 2258 of ForCES PL and is depending upon the type of transport protocol, 2259 nature of connection. 2261 All these configurations should be done prior to starting the CE and 2262 FE. 2264 When certificates-based authentication is being used at TML layer, 2265 the certificate can use ForCES specific naming structure as 2266 certificate names and accordingly the security policies can be 2267 configured at CE and FE. 2269 9.2.1 Endpoint authentication service 2271 When TML security services are enabled. ForCES TML layer performs 2272 endpoint authentication. Security association is established between 2273 CE and FE and is transparent to the ForCES PL layer. 2275 We recommend that FE after establishing the connection with the 2276 primary CE, should establish the security association with the backup 2277 CE (if available). During the switchover operation CE's security 2278 state associated with each SA's are not transferred. SA between 2279 primary CE and FE and backup CE and FE are treated as two separate 2280 SA's. 2282 9.2.2 Message authentication service 2284 This is TML specific operation and is transparent to ForCES PL 2285 layer[TML document]. 2287 9.2.3 Confidentiality service 2289 This is TML specific operation and is transparent to ForCES PL 2290 layer.[TML document] 2292 10. Acknowledgments 2294 The authors of this draft would like to acknowledge and thank the 2295 following: Alex Audu, Steven Blake, Allan DeKok, Ellen M. Deleganes, 2296 Yunfei Guo, Joel M. Halpern, Zsolt Haraszti, Jeff Pickering, 2297 Guangming Wang, Chaoping Wu, and Lily L. Yang for their 2298 contributions. We would also like to thank David Putzolu, and 2299 Patrick Droz for their comments and suggestions on the protocol. 2301 11. References 2303 11.1 Normative References 2305 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 2306 June 1999. 2308 [RFC3654] Khosravi, H. and T. Anderson, "Requirements for Separation 2309 of IP Control and Forwarding", RFC 3654, November 2003. 2311 [RFC3746] Yang, L., Dantu, R., Anderson, T. and R. Gopal, 2312 "Forwarding and Control Element Separation (ForCES) 2313 Framework", RFC 3746, April 2004. 2315 11.2 Informational References 2317 [FE-MODEL] 2318 Yang, L., "ForCES Forwarding Element Model", Feb. 2004. 2320 Author's Address 2322 Avri Doria 2323 ETRI 2325 Phone: +1 401 663 5024 2326 EMail: avri@acm.org 2328 Appendix A. Individual Authors/Editors Contact 2330 Ligang Dong 2331 Zhejiang Gongshang University 2332 149 Jiaogong Road 2333 Hangzhou 310035 2334 P.R.China 2335 Phone: +86-571-88071024 2336 EMail: donglg@mail.hzic.edu.cn 2338 Avri Doria 2339 ETRI 2340 EMail: avri@acm.org 2342 Ram Gopal 2343 Nokia 2344 5, Wayside Road 2345 Burlington MA 01803 2346 USA 2347 Phone: 1-781-993-3685 2348 EMail: ram.gopal@nokia.com 2350 Robert Haas 2351 IBM 2352 Saumerstrasse 4 2353 8803 Ruschlikon 2354 Switzerland 2355 EMail: rha@zurich.ibm.com 2357 Jamal Hadi Salim 2358 Znyx 2359 Ottawa, Ontario 2360 Canada 2361 EMail: hadi@znyx.com 2363 Hormuzd M Khosravi 2364 Intel 2365 2111 NE 25th Avenue 2366 Hillsboro, OR 97124 2367 USA 2368 Phone: +1 503 264 0334 2369 EMail: hormuzd.m.khosravi@intel.com 2370 Weiming Wang 2371 Zhejiang Gongshang University 2372 149 Jiaogong Road 2373 Hangzhou 310035 2374 P.R.China 2375 Phone: +86-571-88057712 2376 EMail: wmwang@mail.hzic.edu.cn 2378 Appendix B. IANA considerations 2380 tbd 2382 Appendix C. Implementation Notes 2384 C.1 TML considerations 2386 Having separated the PL from the TML layer, it became clear that the 2387 TML layer needed to understand the desires of the PL layer to service 2388 it. Example: How does the TML layer map prioritization or 2389 reliability needs of a PL message? To see the challenge involved, 2390 assume that all of the FE TML, FE PL, CE TML and CE PL are 2391 implemented by different authors probably belonging to different 2392 organizations. Three implementation alternatives were discussed. 2394 As an example, consider a TML which defines that PL messages needing 2395 reliability get sent over a TCP connection; then TML-PL interfaces 2396 are: 2397 o PL to call a special API: example send_reliable(msg) which is 2398 translated by the TML to mean send via TCP. 2399 o PL to call a generic API: example send(msg) with explicit msg 2400 flags turned to say "reliability needed" and the TML translates 2401 this to mean send via TCP. 2402 o PL sends the Forces Messages such a message is inferred to mean 2403 send via TCP by the TML. 2405 in #1 and #2 the msg includes a ForCES msg with metadata flags which 2406 are consumed by the TML layer. 2408 #3 is a technique that will be referred as inference-by-TML 2409 technique. It simplifies the standardization effort since both #1 2410 and #2 will require standardization of an API. Two ideas discussed 2411 for TML inference of PL messages are: 2412 1. Looking at the flags in the header. 2413 2. Looking at the message type. 2415 #1 and #2 can still be used if a single organization implements both 2416 (PL and TML) layers. It is also reasonable that one organization 2417 implements the TML and provides an abstraction to another 2418 organization to implement a PL layer on. 2420 C.1.1 PL Flag inference by TML 2421 1. Reliability 2422 This could be "signalled" from the PL to the TML via the ACK 2423 flag. The message type as well could be used to indicate this. 2424 2. No reliability 2425 Could be signalled via missing ACK flag. The message type as 2426 well could be used to indicate this. 2427 3. Priorities 2428 A remapping to be defined via the FEM or the CEM interface 2429 depending on the number of TML priorities available. 2431 4. Addressing 2432 This is TML specific. For example a TML that is capable of 2433 multicast transport may map a multicast PL ID to a multicast 2434 transport address. 2435 5. Event notifications 2436 The TML must be able to send to the PL notifications. 2437 1. The TML should be able to send Transport level congestion 2438 notifications to the PL. 2439 2. Link events for HA purposes if configuration requires it 2440 3. Events that will trigger PL layer events from the TML. 2441 As an example, an HA event at the TML layer like a failure of 2442 CE detected at TML on the FE may belong to this. In this 2443 case, a PL event msg will be triggered and sent to CE. 2444 4. Events that are intrinsic to the same CE or FE a TML is 2445 located. These will not trigger any PL msg, instead, they 2446 just act as notification to PL core (FE object). The 2447 congestion event generated at the transmission source side 2448 may belong to this, because it usually only needs to tell the 2449 upper PL at the same side rather than the opposite side that 2450 congestion has happened along the path. E.g., a congestion 2451 event at CE TML layer only need to tell CE PL of this, rather 2452 than the opposite FE via a PL msg. 2454 C.1.2 Message type inference to Mapping at the TML 2456 In this case one would define the desires of the different message 2457 types and what they expect from the TML. For example: 2458 1. Association Setup, Teardown, Config, Query the PL will expect the 2459 following services from TML: Reliable delivery and highest 2460 prioritization. 2461 2. Packet Redirect, HB Message Types, and Event Reports the PL will 2462 require the following services from TML: Medium Prioritization, 2463 and notifications when excessive losses are reached. 2465 Appendix D. Changes between -00 and -01 2466 1. Major Protocol changes 2467 * Restructured message format to apply operation to LFB as 2468 opposed to having operation be the primary organizing 2469 principle 2470 * Worked with model team to bring the draft into harmony with 2471 their model approach 2472 2. Document changes 2473 * Replaced FE protocol Object and FE Object sections with 2474 combined section on FE, CE and FE protocol LFBs 2475 * Removed minor version id 2476 * Added Header flags 2477 * Added BNF description of message structure 2478 * Added tree structure description of PDUs 2479 * Added section on each type of LFB 2480 * Added structural description of each message 2481 * Moved query messages section to come after config message 2482 section 2483 * Replace state maintenance section 2484 * Added section with tables showing the operations relevant to 2485 particular messages 2486 * Many spelling and grammatical corrections 2488 Intellectual Property Statement 2490 The IETF takes no position regarding the validity or scope of any 2491 Intellectual Property Rights or other rights that might be claimed to 2492 pertain to the implementation or use of the technology described in 2493 this document or the extent to which any license under such rights 2494 might or might not be available; nor does it represent that it has 2495 made any independent effort to identify any such rights. Information 2496 on the procedures with respect to rights in RFC documents can be 2497 found in BCP 78 and BCP 79. 2499 Copies of IPR disclosures made to the IETF Secretariat and any 2500 assurances of licenses to be made available, or the result of an 2501 attempt made to obtain a general license or permission for the use of 2502 such proprietary rights by implementers or users of this 2503 specification can be obtained from the IETF on-line IPR repository at 2504 http://www.ietf.org/ipr. 2506 The IETF invites any interested party to bring to its attention any 2507 copyrights, patents or patent applications, or other proprietary 2508 rights that may cover technology that may be required to implement 2509 this standard. Please address the information to the IETF at 2510 ietf-ipr@ietf.org. 2512 Disclaimer of Validity 2514 This document and the information contained herein are provided on an 2515 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2516 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2517 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2518 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2519 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2520 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2522 Copyright Statement 2524 Copyright (C) The Internet Society (2004). This document is subject 2525 to the rights, licenses and restrictions contained in BCP 78, and 2526 except as set forth therein, the authors retain all their rights. 2528 Acknowledgment 2530 Funding for the RFC Editor function is currently provided by the 2531 Internet Society.