idnits 2.17.1 draft-salim-forces-alt-jhs-00.txt: ** The Abstract section seems to be numbered Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There is 1 instance of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 2001) is 8321 days in the past. Is this intentional? 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: 'RFC-2119' is mentioned on line 34, but not defined == Unused Reference: 'RFC1812' is defined on line 453, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-gsmp-09 Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Jamal Hadi Salim 2 Znyx Networks 3 July 2001 5 Requirements for Separation of IP Control and Forwarding Services 7 draft-salim-forces-alt-jhs-00.txt 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are 13 working documents of the Internet Engineering Task Force (IETF), 14 its areas, and its working groups. Note that other groups may 15 also distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six 18 months and may be updated, replaced, or obsoleted by other 19 documents at any time. It is inappropriate to use Internet-Drafts 20 as reference material or to cite them other than as ``work in 21 progress.'' 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt. 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Conventions used in this document 31 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 32 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 33 this document are to be interpreted as described in [RFC-2119]. 35 1. Abstract 37 This document defines a set of requirements for mechanisms to 38 logically separate the control and data forwarding IP services 39 in an IP network element (NE). 41 Version 0 hadi 43 2. Introduction 45 An IP NE contains two logically separated entities that cooperate 46 to provide services to packets travessing the NE. While separate 47 and have a very well defined logical functions, these entities pro- 48 vide a unified external view of the NE. The NE entities are: con- 49 trol-plane(CP) components and forwarding-Engine(FE) components. 51 It is important to re-emphasize that the FE<->CP interaction, as 52 well as the sole reason for the existence of the CP and FE, is to 53 provide services to IP packets. 55 ForCES attempts to define a clear separation between the two enti- 56 ties of the NE in order to have them evolve separetely as opposed 57 to the current monolithic evolution. 59 2.1. Some definitions 61 A CP may have several CP componets each providing control for a 62 different IP service being executed by a FE component. This means 63 that there will be several CP components on a physical CP if it is 64 controlling several IP services. Likewise for the FE. In essence, 65 the cohesion between a CP component and a FE component is the ser- 66 vice abstraction. 68 In the diagram below we show a simple FE<->CP setup to provide an 69 example of the classical IPv4 service with an extension to do some 70 basic QoS egress scheduling and how it fits in this described 71 model. 73 Version 0 hadi 75 Control Plane (CP) 76 .------------------------------------ 77 | /^^^^^\ /^^^^^\ | 78 | | | | COPS |-\ | 79 | | ospfd | | PEP | \ | 80 | \ / \_____/ | | 81 /------\_____/ | | | 82 | | | | | | 83 Forwading | |________\_____________|___|_________| 84 Engine (FE) | | | | 85 .-------------|-----------|------------|---|----------- 86 | | / | 87 | FE Service / / | 88 | Component / / | 89 | ---------------/---------------/--------- | 90 | | | / | | 91 packet | | --------|-- ----|----- | | packet 92 in | | | IPV4 | | Egress | | | out 93 -->--->|----->|---->| Forwading |----->| QoS |--->| ---->|----> 94 | | | | | Schedule | | | 95 | | ----------- ---------- | | 96 | | | | 97 | --------------------------------------- | 98 | | 99 ------------------------------------------------------- 101 2.1.1. Control Plane Components 103 Control plane components in the ForCES context would encompass sig- 104 nalling protocols with diversity ranging from dynamic routing pro- 105 tocols such as OSPF to tag distribution protocols such as CR-LDP. 106 Classical Management protocols and activities also fall under this 107 category. These include SNMP, COPS or proprietary CLI/GUI configu- 108 ration mechanisms. 110 The purpose of the control plane is to provide an execution envi- 111 ronment for the above mentioned activities with the ultimate goal 112 to configure and manage the second NE component: the FE. The result 113 of the configuration would define the way packets travesing the FE 114 are treated. 116 The CP components are traditionaly run in software since they tend 117 to be very rich in syntax and are moving targets requiring ease of 119 Version 0 hadi 121 modification. 123 In the above diagram, ospfd and COPS are distinct control plane 124 components. 126 2.1.2. Forwarding Engine Components 128 The FE is the entity of the NE that incoming packets (from the net- 129 work into the NE) first encounter. 131 The FE's service specific component massages the packet to provide 132 it with a treatment to achieve a IP service as defined by the con- 133 trol plane components for that IP service. Different services will 134 utilize different FE components. Service modules maybe chained to 135 achieve a more complex service (as shown in the diagram). When 136 built for providing a specific service, the FE service component 137 will adhere to a Forwading Model (to use ForCES charter speak) for 138 that service. 140 The FE could be implemented in software, ASICs, or Network Proces- 141 sors(NPs). Classical approach is to have a mixture of ASICs and 142 software. We will not delve into design of an FE but rather focus 143 on its purpose. 145 In the above diagram, the FE components include both the IPV4 For- 146 warding module as well as the Egress Scheduling module. Another 147 service might just replace the IPV4 forwarder module with a web- 148 switch forwarder. A simpler classical service would have consti- 149 tuted only the IPV4 forwarder. 151 2.1.3. IP Services 153 An IP Service is the treatment of an IP packet within the NE. 155 The time span of the service is from the moment when the packet 156 arrives at the NE to the moment it departs. In essence an IP ser- 157 vice in this context is a Per-Hop Behavior. A service control/sig- 158 naling protocol/management-application (CP components running on 159 NEs defining the end to end path) unifies the end to end view of 160 the IP service. As noted above, these CP components then define the 161 behavior of the FE (and therefore the NE) to a described packet. 163 Version 0 hadi 165 A simple example of an IP service is the classical IPv4 Forwading. 166 In this case, control components such as routing protocols(OSPF, 167 RIP etc) and proprietary CLI/GUI configurations modify the FE's 168 forwarding tables in order to offer the simple service of forward- 169 ing packets to the next hop. Traditionally, NEs offering this sim- 170 ple service are known as routers. 172 Over the years it has become important to add aditional services to 173 the routers to meet emerging requirements. More complex services 174 extending classical forwarding were added and standardized. These 175 newer services might go beyond the layer 3 contents of the packet 176 header. However, the name "router", although a misnomer, is still 177 used to describe these NEs. Services (which may look beyond the 178 classical L3 headers) here include firewalling, Qos in Diffserv and 179 RSVP, NATs, policy based routing etc. Newer control protocols or 180 management activities are introduced with these new services. 182 Given the observed evolution path, a very important intent is not 183 to limit what an IP service should be. Rather leave the service 184 definition flexible enough to not restrict future innovation. For 185 example, one should be easily be able to integrate the services 186 being defined by OPES within the ForCES model. 188 One extreme definition of a IP service is something a service 189 provider would be able to charge for. 191 3. Architectural Requirements 193 Below is a diagram illustrating an example NE composed of one CE 194 and two FEs connected by a switching fabric. 196 Version 0 hadi 198 ------------------------------- 199 | NE | 200 | ------------ | 201 | | CE | | 202 | ------------ | 203 | | | 204 | | | 205 | ------------ | 206 | | SWITCH | | 207 | | FABRIC | | 208 | ------------ | 209 | / \ | 210 | / \ | 211 | ----------- ----------- | 212 | | FE | | FE | | 213 | ----------- ----------- | 214 | | | | | | | | | | 215 | | | | | | | | | | 216 | | | | | | | | | | 217 | | | | | | | | | | 218 ------------------------------- 219 | | | | | | | | 220 | | | | | | | | 222 (1) The CP and FE (and their components) MUST communicate via the 223 ForCES protocol in the IP service definition. 225 (2) The CP and FE MAY reside on different physical devices. 227 (3) The CP and FE MUST have a way to connect to each other. This MAY be 228 using any mechanism of convinience. Examples of known interconnect 229 mechanisms are Ethernet connections, proprietary backplanes, open 230 standard buses (such as PCI), ATM (cell) fabrics, and abstractions 231 such as sockets. Addressing to the FE is defined by access method. 233 (4) There is a cohesiveness between a CP component and an FE component 234 as defined by an IP service they are trying to deliver. This is the 235 only restriction in the architecture i.e there is no other direct 236 linkage between an FE and CP. A CP component MAY control several 237 FEs which may reside on different physical devices; vice-versa, 238 there MAY be more than one CP(component) controlling a single FE 239 (service). [Think of several routing daemons each running a differ- 240 ent routing protocol trying to configure a Forwading service. The 241 FE component being configured in the described service is responsi- 242 ble of the serialization (eg shared access of its tables).]. A 243 direct consequence of this requirement is that several FE 245 Version 0 hadi 247 components and hence several IP services can run on a single FE. 249 This ability to extend the number of physical CPs and FEs allows 250 ForCES architecture to scale. 252 (5) There MAY be mechanisms for CEs and FEs to discover each other 253 without apriori configuration. There MUST be a simple mechanism 254 such as static setup to allow this. 256 (6) There MUST be a mechanism by which CEs and FEs can be authenticated 257 to prevent unauthorized components from joining the network ele- 258 ment. 260 (7) In the case of a CP residing on a remote device or on some propri- 261 etary device, it MAY have a proxy on an FE controller. The protocol 262 between the proxy and FE MUST be that defined by ForCES. The pro- 263 tocol between the device and the CP is left to the implementation. 265 (8) The scope of the ForCES problem is only focussed on CP<->FE commu- 266 nication. CP or FE services that require to have other forms of 267 architectures (such as HA and redundancy) MUST define their own 268 methodology. This will help keep ForCES simple. 270 4. FE Services 272 These are services that the FE provides to either CP components or 273 FE components. Note that we are refering to the FE-in-general here 274 and that these are not IP services although will be communicated 275 via the ForCES protocol. It is important to separate what the gen- 276 eral FE provides in terms of resource and event management and the 277 FE component in terms of IP service execution. The FE component 278 events are only available when the FE component (or service) is 279 active; the FE events are available at any time the FE is up. An 280 FE model description (in addition to an FE component model which is 281 a MUST for an IP service) MAY be required to express these simple 282 services. 284 Generally, FE or CP components subscribe to listen to FE events in 285 order to properly deliver the service value. For example, a FE com- 286 ponent would rather not send to a downned interface and the CP com- 287 ponent would notify its peers of the downed interface so better 288 service connectivity decisions can be made amongst the peers. 290 The CP component of a IP service might also ask the FE for packet 291 redirection to itself for the purposes of providing the IP service. 293 Version 0 hadi 295 The control and management of resources within a FE is not within 296 the mandate of ForCES. It is assumed some other mechanisms are 297 responsible. 299 (1) Port Functions 301 When queried, the FE MUST be capable of expressing the number of 302 ports on the device,the static attributes of each port (e.g., port 303 type, link speed), and the configurable attributes of each port 304 (e.g., IP address, administrative status). 306 (2) Event Capability discovery 308 The FE MAY be capable of expressing the types of asynchronous 309 events (e.g., link up/down, redirected packet, out of memory) that 310 a FE will generate. Common events and their templates MUST be stan- 311 dardized, similar to those for well known services described in the 312 next section. Example here are those of link maintanance and those 313 already standardized by GSMP for port events. 315 (3) Event Notification 317 The FE SHOULD be capable to deliver its events to subscribed compo- 318 nents. 320 (4) Vendor-Specific Functions 322 The FE SHOULD be extensible so that vendor-specific event notifica- 323 tion can be offered. 325 (5) Network Management capability Discovery 327 The FE MAY be capable of expressing the types of statistics for the 328 resources it manages when queried. 330 (6) Network Management 332 The FE MUST be capable of delivering statistics for the resources 333 it manages when queried. 335 (7) Request For Packets 337 The FE MUST be capable of delivering packets or copies of requested 338 packets to the CP. Normally, these would be control packets that 339 belong to an IP service. The CP component of the IP service would 340 request to have the FE send all control packets to it. An example 341 here would be all OSPF packets being passed to ospfd in diagram 1. 343 Version 0 hadi 345 Another example would be all TCP SYN and FIN packets in a split-TCP 346 webswitch to a specific service CP component on the physical CP. 348 5. IP Service Requirements 350 (1) An IP service is delivered to customer packets by the cohesive 351 effort of the service's CP and FE components. The components MAY 352 subscribe to FE services in order to better deliver services. 354 As an example in diagram 1 above, ospfd and COPS both work with 355 their two FE counterparts to cohesively deliver an abstracted IP 356 service which both forwards IPV4 packets and provides selective 357 Egress QoS to customer packets. 359 Both will be subscribed to FE services on link events as well as FE 360 services to deliver their respective protocol packets. 362 (2) Services MUST be defined using templates such as those found in 363 GSMP[GSMP]. This will allow for simpler mechanisms for FE capabil- 364 ity and service discovery. [Note the difference between GSMP and 365 ForCES templates is that while GSMP's define switch connection man- 366 agement, ForCES' defines service management]. 368 (3) Well known services MUST have their templates standardized. Example 369 of well known services here includes the classical RFC1812 router 370 and well known extensions to RFC1812 such as Diffserv and policy 371 based routing. All standardized services MUST be issued "service 372 Numbers". 374 (4) A range of service numbers MUST be reserved for the Opaque service. 375 This is a service that could be user defined. It will allow for 376 faster deployment of newly innovated services without requiring 377 standardization. This would also allow for vendor specific exten- 378 sions. 380 6. Protocol Requirements 382 (1) The ForCES protocol interconnects the FE service portions to their 383 controllers (CPs). Different types of services will have different 384 protocol requirements. It is therefore imperative to not enforce a 385 service to a specific protocol. Rather have the service choose from 386 a set of available mechanisms to define the protocol set. 388 Version 0 hadi 390 (2) The main activities foreseen in the protocol are: discovery, con- 391 figuration, event notification and statistical querying. 393 (3) In order for the FE and CE components of a network element to act 394 in concert, they need to discover each other. At the minimalist 395 level the discovery phase is hardcoded by static entries. At a 396 slightly higher level is dynamic discovery. Using service tem- 397 plates allows ForCES to re-use many of the existing Service Discov- 398 ery protocols and benefit from their operational experiences and 399 wider deployment. Example of service discovery protocols include: 400 Universal Plug-and-play, Jini, Bluetooth's SDP and SLP. 402 (4) After the FE discovers their CPs of choice and negotiated the ser- 403 vice contract, the established phase is entered. In this phase the 404 CP and FE components participate in service delivery. This includes 405 configuration, event notification, and statistical as well as con- 406 fig queries. 408 (5) An FE component may choose at any time to terminate its contract 409 with the CP component (and may join a different CP, for example. 410 This is left to the specific service). 412 (6) There MUST be a mechanism to allow a service connection between a 413 FE component and a CP component to have choice of either being 414 reliable or non-reliable communication or a mixture of the two in 415 the context of the activities in the established phase. 417 (7) There MUST be a mechanism by which CEs and FEs can quickly deter- 418 mine when a loss of connectivity between them has occurred. The 419 policy definition MUST be left upto the IP service. 421 (8) Since FE configuration contains information critical to the func- 422 tioning of a network any protocols defined MUST support a method of 423 securing communication between FEs and CEs to ensure that informa- 424 tion is delivered securely in an unmodified form in the established 425 phase. 427 (9) A mechanism for Authentication, Authorization and Accounting MUST 428 be provided. 430 7. Protocol Applicability statement 432 With the clear separation between CPs and FEs that ForCES is striv- 433 ing for, and more precisely with use of the IP service abstraction, 434 the ForCES protocol becomes usable in other WG areas which have 436 Version 0 hadi 438 similar setups. These range from the MIDCOM protocol to the proto- 439 col for configuring an OPES device and all sorts of layer 3 440 devices. One could venture into the Sub-IP area of CCAMP (but that 441 is better suited to GSMP). 443 8. Security Considerations 445 Refer to requirement 8) of the protocol requirements. 447 9. References 449 [GSMP] A. Doria, F. Hellstrand, K. Sundell, T. Worster 450 "General Switch Management Protocol V3", draft-ietf-gsmp-09.txt 451 June, 2001 453 [RFC1812] F. Baker et al, "Requirements for IP Version 4 Routers", 454 RFC 1812, June 1995. 456 10. Acknowledgements 458 Authors of internet draft draft-anderson-forces-req-02.txt from 459 which this draft is derived. 461 11. Author's Address: 463 Jamal Hadi Salim 464 Znyx Networks 465 Ottawa, Canada