idnits 2.17.1 draft-bitar-i2rs-service-chaining-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 7. Security Considerations' ) ** 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.) (A line matching the expected section header was found, but with an unexpected indentation: ' 6. IANA Considerations' ) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 14, 2014) is 3718 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force 3 I2RS working group N. Bitar 4 Internet Draft Verizon 5 Category: Informational G. Heron 6 L. Fang 7 Microsoft 8 R. Krishnan 9 Brocade Communications 10 N. Leymann 11 Deutshe Telekom 12 H. Shah 13 Ciena 14 S. Chakrabarti 15 W. Haddad 16 Ericsson 18 Expires: August 2014 February 14, 2014 20 Interface to the Routing System (I2RS) for Service Chaining: 21 Use Cases and Requirements 23 draft-bitar-i2rs-service-chaining-01 25 Abstract 27 Service chaining is the concept of applying an ordered set of 28 services to a packet or a flow. Services in the chain may 29 include network services such as load-balancing, firewalling, 30 intrusion prevention, and routing among others. Criteria for 31 applying a service chain to a packet or flow can be based on 32 packet/flow attributes that span the OSI layers (e.g., physical 33 port, Ethernet MAC header information, IP header information, 34 transport, and application layer information). This document 35 describes use cases and I2RS (Information to the Rousting 36 System) requirements for the discovery and maintenance of 37 services topology and resources. It also describes use cases 38 and I2RS requirements for controlling the forwarding of a 39 packet/flow along a service chain based on packet/flow 40 attributes. 42 Status of this Memo 44 This Internet-Draft is submitted to IETF in full conformance 45 with the provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet 48 Engineering Task Force (IETF), its areas, and its working 49 groups. Note that other groups may also distribute working 50 documents as Internet-Drafts. 52 Internet-Drafts are draft documents valid for a maximum of six 53 months and may be updated, replaced, or obsoleted by other 54 documents at any time. It is inappropriate to use Internet- 55 Drafts as reference material or to cite them other than as 56 "work in progress." 58 The list of current Internet-Drafts can be accessed at 59 http://www.ietf.org/ietf/1id-abstracts.txt. 61 The list of Internet-Draft Shadow Directories can be accessed 62 at http://www.ietf.org/shadow.html. 64 This Internet-Draft will expire on August 14, 2014. 66 Copyright Notice 68 Copyright (c) 2014 IETF Trust and the persons identified as the 69 document authors. All rights reserved. 71 This document is subject to BCP 78 and the IETF Trust's Legal 72 Provisions Relating to IETF Documents 73 (http://trustee.ietf.org/license-info) in effect on the date of 74 publication of this document. Please review these documents 75 carefully, as they describe your rights and restrictions with 76 respect to this document. Code Components extracted from this 77 document must include Simplified BSD License text as described 78 in Section 4.e of the Trust Legal Provisions and are provided 79 without warranty as described in the Simplified BSD License. 81 Conventions used in this document 83 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 84 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 85 "OPTIONAL" in this document are to be interpreted as described 86 in RFC-2119 [RFC2119]. 88 Table of Contents 90 1. Introduction..............................................4 91 2. Abbreviations and Definitions.............................5 92 2.1. Abbreviations........................................5 93 2.2. Definitions..........................................5 94 3. Service Chaining Use Cases and Requirements...............5 95 3.1. Services topology....................................5 96 3.2. Monitoring Information...............................8 97 3.3. Traffic Redirection, Forwarding and Service Chaining.9 98 4. Service Chaining via BGP-based Redirection...............12 99 5. Operational Considerations...............................13 100 6. IANA Considerations......................................13 101 7. Security Considerations..................................13 102 8. Acknowledgements.........................................13 103 9. References...............................................13 104 9.1. Normative References................................13 105 9.2. Informative References..............................14 106 Authors' Addresses..........................................14 108 1. Introduction 110 Several networking scenarios involve applying a set of services 111 to a packet or flow. For instance, when a host in a protected 112 zone initiates a session to a server outside the zone, the 113 session may be directed to a chain of a Wide Area Network (WAN) 114 application acceleration service, a network address and port 115 translation (NAPT) service, and a firewall. On the server side, 116 another set of services may also be applied. Such a sequence of 117 services applied to a packet or flow is referred to as a 118 service chain. Services in the chain may include deep packet 119 inspection (DPI), load-balancing, firewalling, intrusion 120 prevention, and routing among others. 122 Criteria for applying a service chain to a packet or flow can 123 be based on packet/flow attributes that span the OSI layers. 124 Such attributes may include the physical/virtual port on which 125 the packet arrives, Ethernet MAC header information (e.g., VLAN 126 ID), IP header information (e.g., source IP address), transport 127 header information (e.g., TCP destination port number), and 128 application layer information among others. 130 The transition from one service to the next in a service chain 131 may be conditioned on the output of the current service, or may 132 be non-conditional (pre-determined). A new mechanism, to be 133 defined, may also enrich the packet transition in a service 134 chain by passing service-specific information and/or 135 information pertaining to preceding services in the chain along 136 with the packet being processed. This type of mechanism and its 137 influence are outside the scope of this document. In addition, 138 this version of the document addresses the simple use case of 139 pre-determined service chains applied to non-dropped packets 140 with no additional information from preceding services. The 141 service path for a packet/flow may be established via a 142 management plane or routing, and may be enforced in the data 143 plane via different mechanisms, as discussed in this document. 145 Services in a chain can be co-located on one system and/or 146 physically separated across systems. In either case, a service 147 may be running in its own virtualized system space or natively 148 on the hosting system. 150 This document describes use cases and I2RS [i2rs-prob] 151 requirements for the discovery and maintenance of services 152 topology and resources. It also describes use cases and I2RS 153 requirements for controlling the forwarding of a packet/flow 154 along a service chain based on packet/flow attributes. 156 2. Abbreviations and Definitions 158 2.1. Abbreviations 160 2.2. Definitions 162 3. Service Chaining Use Cases and Requirements 164 A service chain is an ordered set of services applied to a 165 packet or flow. It is often the case that when a flow in a 166 bidirectional session is assigned to a service chain, the 167 reverse flow of the same session is required to traverse the 168 same chain in the reverse order. Assigning a flow to a service 169 chain is often defined at an abstract level. Mapping a service 170 chain to a network requires knowledge of the available services, 171 their locations and available resources so that services are 172 properly engineered on the services infrastructure. This 173 section describes requirements and applicability for such 174 information, and for directing traffic through a service chain. 176 3.1. Services topology 178 In order to establish a service chain that applies to a 179 packet/flow, it is important to have a topology of the service 180 nodes. A service node can be a service running natively within 181 a system (e.g., a service card or a service engine in a 182 router), a virtual machine (VM) hosted on a server, a VM hosted 183 on a service engine within a system (e.g., a service card in a 184 router), or a dedicated standalone service hardware appliance. 185 In addition, a service node may be dedicated to a customer 186 (e.g., an IPVPN customer), globally shared across customers or 187 a customer set of VPNs, or available to be assigned in whole or 188 in part to a customer or a set customer VPNs. A customer and 189 tenant are used synonymously in this document. How a service 190 node is created is outside the scope of this document. 191 Resources on a service node that are not assigned to a customer 192 context (e.g., VRF) will be logically referred to as a non- 193 assigned service node with free available resources. A service 194 node that can be shared in a global context will be referred to 195 as a global service node. It should be noted, that once a 196 service node is bound to a context, then it is only available 197 for a virtual network (VN) associated with that context. 199 Different service node types may have information specific to 200 the service(s) they provide. A service node information model 201 needs to describe information common (generic) to all service 202 node types and extensible to be sub-classed so that the service 204 specific information can be represented. The common information 205 is: 207 . 208 Service node address: A service node must have a unique 209 address in a service topology. A service node identifier 210 address can be: 212 o An IP address when feasible. Such a service node can 213 be a VM, a services engine within a system, or a 214 hardware appliance. 216 o The tuple (service node IP address, hosting system IP 217 address). This applies when there is need to identify 218 the system hosting the service node or when the 219 service node IP address is only reachable within the 220 hosting system. 222 o The tuple (hosting system IP-address, system internal 223 identifier for the service engine). This applies when 224 the service engine is not IP addressable and is within 225 a system. A potential system internal identifier for a 226 service engine may be 227 (system_slot_number.subslot_number.engine_number). 229 . 230 For each service node, the following information is 231 required: 233 o Supported service type (e.g., NAT, FW). A node may 234 support multiple service types. 236 o Number of virtual contexts (tenants) that can be 237 supported. This parameter will indicate the maximum 238 number of contexts that can be created on the service 239 node. 241 o Number of virtual contexts (e.g., VRFs) available. 243 o Supported context type (e.g., VRF). 245 o Customer ID if the service node is dedicated to a 246 customer. This indicates who can use this service 247 node. 249 o List of supported (customer ID, virtual contexts). 250 Note that one context per customer is a degenerate 251 case. This will be the global context for a given 252 customer on a service node. 254 For each service node, virtual context and service type, 255 the following information may be specified, depending on 256 the service resource requirement. That is, some of the 257 information listed here may not be relevant for some 258 services. 260 o Service bandwidth capacity 262 o Supported Packet rate (packets per second) 264 o Supported Bandwidth (e.g., in kbps) 266 o IP Forwarding Information Base size per address family 268 o Routing Information Base size 270 o MAC Forwarding database size 272 o Number of 64-bit statistics counters for policy-based 273 accounting 275 o Number of supported Access lists (ACLs) per type 276 (e.g., number of bits per ACL, and ACL type if 277 applicable) 279 o Number of supported flows for services that require it 280 (e.g., Firewall, NAT, stateful load-balancing, Deep 281 Packet Inspection (DPI)) per flow type (i.e., fields 282 identifying a flow) or flow identification key size. 283 For systems that allow flexible memory usage across 284 flow types and/or key sizes, it is sufficient to track 285 available memory allocated for flows. 287 In addition to the services topology, it is important to have a 288 view of the Virtual Network (VN) topology (VNT) and access 289 points to which a services topology applies. The topology of 290 such a VN could be relatively static, but it may also be 291 dynamic, especially in a cloud environment where compute, 292 storage, applications and associated networks may be created 293 and removed over a short time scale. The description of a VN 294 topology encompassing the access points is important in order 295 to enable installation of policies for service chaining at the 296 right access points, instantiate the services if needed, and 297 perform the necessary monitoring as described in later 298 sections. VN topology information requirements are described in 299 [i2rs-topology-reqts], but they need to be augmented with the 300 following information: 302 . Access ports (systems and ports) per VN. A port may be 303 physical or logical on a physical port. 305 . Addresses reachable on an access port. 307 3.2. Monitoring Information 309 Service chaining requires the ability to monitor the state of 310 each service node, including liveliness and resource 311 utilization. If a service node failure is detected, an action 312 may be taken to create another service node and steer traffic 313 to it. If a service node is hitting a resource utilization 314 threshold, traffic may be directed to other service nodes, 315 and/or additional service nodes may be created. 317 The following is a set of parameters that needs be monitored 318 per service node per virtual context, and per service type as 319 applicable. It should be noted that some services may not 320 require all the parameters listed here to be monitored. 322 . Bandwidth utilization (e.g., in kbps) 324 . Packet rate utilization (packets per second) 326 . Bandwidth utilization per CoS (e.g., in kbps) 328 . Packet rate utilization per Cos 330 . Memory utilization and available memory 332 . RIB utilization per address family 334 . FIB utilization per address family 336 . Flow resource utilization per flow type 338 . CPU utilization as applicable 340 . Available storage 342 The following is a set of parameters that needs to be monitored 343 globally per physical system (e.g., host server) providing 344 services or hosting service nodes. Note that some parameters 345 may not be needed for some services: 347 . Bandwidth utilization (e.g., in kbps) 348 . Packet rate utilization (packets per second) 350 . Bandwidth utilization per Class of Service (CoS) 352 . Packet rate per CoS (packets per second) 354 . Memory utilization and available memory 356 . RIB utilization and available RIB memory if applicable per 357 address family 359 . FIB utilization and available FIB entries if applicable 360 per address family 362 . Flow resource utilization per flow type if applicable 364 . CPU utilization if applicable 366 . Power utilization 368 . Available storage 370 Such information needs to be maintained on the distributed 371 system hosting a service node, and/or service node as 372 applicable. In addition, a mechanism to monitor the liveliness 373 of a service node must be available. For some use cases, 374 liveliness and resource utilization information needs to be 375 accessible to a management/control plane that provides for 376 creation of service nodes and orchestration of service chains. 377 Some of this information may also be maintained in the 378 management/orchestration system and validated with the 379 distributed system where the services are instantiated. For 380 some other use cases, a service node and/or hosting system may 381 need to be programmed to update a management system with that 382 information periodically or when a configured high watermark or 383 low watermark is reached for a parameter. Thus, the interface 384 to the service nodes and/or hosting systems must provide a 385 mechanism that enables a management/control system to pull 386 resource utilization information from these nodes and systems, 387 and for these nodes and system to send updates on resource 388 utilization to a designated system. 390 3.3. Traffic Redirection, Forwarding and Service Chaining 392 In a service chain, it is important to be able to direct 393 traffic from one service node to another. Some solutions may 394 provide this capability via dynamic routing, data-plane based 395 policy-based routing, source based routing or a combination. 396 Traffic redirection to a service chain requires the ability to 397 program the routing system with a classification rule that 398 identifies a packet/flow and an associated action that directs 399 the corresponding packet(s) to the first node in the service 400 chain. The focus in this section is on a hop-by-hop policy- 401 based routing (PBR) and source based service routing. At the 402 redirection point, classification rules MUST support the 403 following information that encompasses Layer1-7 information, 404 any of which may be wild-carded or left unspecified for a 405 particular case: 407 . Port 409 . VLAN/VLAN stack 411 . MAC source address 413 . MAC destination address 415 . Host/subnet Source IP address 417 . Host/subnet Destination IP address 419 . IP version 421 . IP protocol 423 . Source port/port-range 425 . Destination port/port-range 427 . Optionally, application-layer information such as key 428 words in a URI, content type or user agent 430 As a result of the classification, an action will need to be 431 specified to direct the matching packet to a service node, or 432 to perform other action(s). The following actions MUST be 433 supported: 435 . Forward to a specified Outgoing port (physical or 436 logical): 438 o VLAN ID 440 o IP/GRE tunnel 441 o RSVP-TE tunnel 443 o Pseudowire (PW) 445 o Other types of tunneling protocols 447 . Steer the packet to a VRF 449 . Mirror packet: 451 o To an IP destination 453 o To a port 455 o over a VLAN 457 o over an IP/GRE tunnel 459 o over an RSVP-TE tunnel 461 o over a Pseudowire 463 o over other types of tunneling 465 . Route. This could be the default behavior at the tail end 466 of a chain or the result of no match. 468 . Route the packet to a specific system that is multiple IP 469 hops away (Layer 3 policy based routing). The destination 470 system IP address must be specified along with the 471 tunneling type. The action must result in encapsulating 472 the packet to the destination. At the destination, a 473 policy must be installed to apply a service in a specific 474 context to the arriving packet, or direct the traffic to a 475 local service node. 477 . Insert a source route header in the transmitted packet 478 that identifies the nodes along the service path. The 479 service route may be composed of IPv4 routes, IPv6 routes 480 and/or a stack of MPLS labels. The source route may 481 capitalize on existing mechanism or new mechanisms that 482 are outside the scope of this document. At the 483 destination, a policy must be installed to apply a service 484 in a specific context to the arriving packet, or direct 485 the traffic to a local service node. 487 . Insert a source route+service header that identifies the 488 service path and the service type to be applied at each 489 node. This will require the definition of a new data plane 490 header that carries such information. 492 The number of classification rules and associated actions, as 493 well as the rate of programmability/removal of these rules will 494 be highly application dependent. When the service chain is 495 based on static policy (e.g., applied to a port, a source 496 subnet, a VN), these rules will be programmed on a system at 497 the rate of provisioning. When the attributes of the policies 498 are relatively static (e.g., applied to a fixed port in fixed 499 wireline access), the rate of provisioning on the forwarding 500 system could be low, on the order of few hundred per day. When 501 the attributes are more dynamic, such as in a mobile 502 environment on a system handling a large number of users, that 503 rate could be much higher. In a cloud environment where tenant 504 systems may be spun up and removed on a relatively short time 505 scale this rate could be on the order of few hundreds to 506 thousands a minute at a DC GW for instance. In all cases, if 507 the state is not kept in a persistent storage on the forwarding 508 system(s), system reboot actions will trigger the need for a 509 high provisioning rate, on the order at few thousands per 510 second. When policies are triggered by data-plane, the rate of 511 policy provisioning will be on the order of flow rates and 512 removal will be dependent on the flow duration. These rates 513 will be highly dependent on the applications as well, but at a 514 system that is handling a large number of flows, the protocol 515 used in provisioning must be very efficient to handle a very 516 large number of flows. 518 4. Service Chaining via BGP-based Redirection 520 BGP-based steering of a traffic flow to a first service point 521 may be required in certain cases. In this case, a router 522 hosting a service node or connected to a service node will 523 advertise a flow specification that causes a system that 524 receives the advertisement to redirect a packet or mirror a 525 copy of the packet that matches the flow specification to the 526 advertising route [BGP-flowspec]. When the advertising router 527 supports the i2rs BGP service, ann I2RS interface to the router 528 can provision the router with the appropriate BGP policy as 529 well as install on that router a forwarding policy that directs 530 the packet when received to the appropriate service node. Such 531 BGP advertisements can be chained to effect the chaining of 532 multiple services. 534 5. Operational Considerations 536 6. IANA Considerations 538 There is IANA action required by this document. 540 7. Security Considerations 542 Service chaining imposes several security issues that must be 543 addressed. First, the control system that installs policies on 544 the routing system must be trusted by that system. An untrusted 545 control system may install policies that hijack traffic, cause 546 denial of service, or mirror traffic to an untrusted entity for 547 eavesdropping. Thus the communication channel between a control 548 system and routing system must be authenticated, and may be 549 encrypted. In addition, when services are being offered to 550 multiple VPN customers with overlapping IP addresses, it is 551 important that the customer privacy is maintained when applying 552 a service chain to a customer packet/flow. Thus, the ability to 553 identify the context in which a service needs to be applied is 554 important. In addition, policies must be installed in the 555 appropriate context. Finally, congesting a service node can 556 result in packet drops that may effectively result in a denial 557 of service. Thus, obtaining information about the performance 558 of a service node is important to detect overload conditions 559 and take corrective action. 561 8. Acknowledgements 563 The authors thank David McDysan and Alia Atlas for their comments. 565 9. References 567 9.1. Normative References 568 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 569 Requirement Levels", BCP 14, RFC 2119, March 1997. 571 [i2rs-prob] Atlas, A., Nadeau, T., and Ward, D., "Interface to the 572 Routing System Problem Statement", draft-ietf-i2rs-problem- 573 statement-00, August 2013. Work in progress. 575 [i2rs-topology-reqts] Medved, J., et al., "Topology API 576 Requirements", draft-medved-i2rs-topology-requirements, February 577 2013. Work in progress. 579 [BGP-flowspec] Uttaro, J., et al., "BGP Flow-Spec Extended 580 Community for Traffic Redirect to IP Next Hop", draft-simpson-idr- 581 flowspec-redirect-02, November 2012. Work in Progress. 583 9.2. Informative References 585 Authors' Addresses 587 Nabil Bitar 588 Verizon 589 60 Sylvan Rd. 590 Waltham, MA 02145 591 EMail: nabil.n.bitar@verizon.com 593 Giles Heron 594 Cisco Systems 595 EMail: giheron@cisco.com 597 Luyuan Fang 598 Microsoft 599 EMail: luyuanf@gmail.com 601 Ram Krishnan 602 Brocade Communications 603 San Jose, CA 95134 604 EMail: ramk@brocade.com 606 Nicolai Leymann 607 Deutsche Telekom 608 Winterfeldtstrasse 21-27 609 10781 Berlin 610 Germany 611 EMail: n.leymann@telekom.de 613 Himanshu Shah 614 Ciena 615 EMail: hshah@ciena.com 617 Samita Chakrabatri 618 Ericsson 619 EMail: samita.chakrabarti@ericsson.com 621 Wassim Haddad 622 Ericsson 623 EMail: wassim.haddad@ericsson.com