idnits 2.17.1 draft-bitar-i2rs-service-chaining-00.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 9 longer pages, the longest (page 3) being 65 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 15, 2013) is 3936 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'RFC2119' is mentioned on line 87, but not defined Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 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 Cisco 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: January 2014 July 15, 2013 20 Interface to the Routing System (I2RS) for Service Chaining: 21 Use Cases and Requirements 23 draft-bitar-i2rs-service-chaining-00 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 January 14, 2014. 66 Copyright Notice 68 Copyright (c) 2013 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 93 2.1. Abbreviations........................................ 5 94 2.2. Definitions.......................................... 5 95 3. Service Chaining Use Cases and Requirements............... 5 97 3.1. Services topology.................................... 5 98 3.2. Monitoring Information............................... 8 99 3.3. Traffic Redirection, Forwarding and Service Chaining.10 100 4. Service Chaining via BGP-based Redirection............... 12 102 5. Operational Considerations............................... 12 103 6. IANA Considerations...................................... 12 104 7. Security Considerations.................................. 13 106 8. Acknowledgements......................................... 13 108 9. References............................................... 13 109 9.1. Normative References................................ 13 110 9.2. Informative References.............................. 14 111 Authors' Addresses.......................................... 14 113 1. Introduction 115 Several networking scenarios involve applying a set of services 116 to a packet or flow. For instance, when a host in a protected 117 zone initiates a session to a server outside the zone, the 118 session may be directed to a chain of a Wide Area Network (WAN) 119 application acceleration service, a network address and port 120 translation (NAPT) service, and a firewall. On the server side, 121 another set of services may also be applied. Such a sequence of 122 services applied to a packet or flow is referred to as a 123 service chain. Services in the chain may include deep packet 124 inspection (DPI), load-balancing, firewalling, intrusion 125 prevention, and routing among others. 127 Criteria for applying a service chain to a packet or flow can 128 be based on packet/flow attributes that span the OSI layers. 129 Such attributes may include the physical/virtual port on which 130 the packet arrives, Ethernet MAC header information (e.g., VLAN 131 ID), IP header information (e.g., source IP address), transport 132 header information (e.g., TCP destination port number), and 133 application layer information among others. 135 The transition from one service to the next in a service chain 136 may be conditioned on the output of the current service, or may 137 be non-conditional (pre-determined). A new mechanism, to be 138 defined, may also enrich the packet transition in a service 139 chain by passing service-specific information and/or 140 information pertaining to preceding services in the chain along 141 with the packet being processed. This type of mechanism and its 142 influence are outside the scope of this document. In addition, 143 this version of the document addresses the simple use case of 144 pre-determined service chains applied to non-dropped packets 145 with no additional information from preceding services. The 146 service path for a packet/flow may be established via a 147 management plane or routing, and may be enforced in the data 148 plane via different mechanisms, as discussed in this document. 150 Services in a chain can be co-located on one system and/or 151 physically separated across systems. In either case, a service 152 may be running in its own virtualized system space or natively 153 on the hosting system. 155 This document describes use cases and I2RS [i2rs-prob] 156 requirements for the discovery and maintenance of services 157 topology and resources. It also describes use cases and I2RS 158 requirements for controlling the forwarding of a packet/flow 159 along a service chain based on packet/flow attributes. 161 2. Abbreviations and Definitions 163 2.1. Abbreviations 165 2.2. Definitions 167 3. Service Chaining Use Cases and Requirements 169 A service chain is an ordered set of services applied to a 170 packet or flow. It is often the case that when a flow in a 171 bidirectional session is assigned to a service chain, the 172 reverse flow of the same session is required to traverse the 173 same chain in the reverse order. Assigning a flow to a service 174 chain is often defined at an abstract level. Mapping a service 175 chain to a network requires knowledge of the available services, 176 their locations and available resources so that services are 177 properly engineered on the services infrastructure. This 178 section describes requirements and applicability for such 179 information, and for directing traffic through a service chain. 181 3.1. Services topology 183 In order to establish a service chain that applies to a 184 packet/flow, it is important to have a topology of the service 185 nodes. A service node can be a service running natively within 186 a system (e.g., a service card or a service engine in a 187 router), a virtual machine (VM) hosted on a server, a VM hosted 188 on a service engine within a system (e.g., a service card in a 189 router), or a dedicated standalone service hardware appliance. 190 In addition, a service node may be dedicated to a customer 191 (e.g., an IPVPN customer), globally shared across customers or 192 a customer set of VPNs, or available to be assigned in whole or 193 in part to a customer or a set of customer VPNs. the terms 194 "customer" and "tenant" are used synonymously in this document. 195 How a service node is created is outside the scope of this 196 document. Resources on a service node that are not assigned to a 197 customer context (e.g., VRF) will be logically referred to as a 198 non-assigned service node with free available resources. A 199 service node that can be shared in a global context will be 200 referred to as a global service node. It should be noted, that 201 once a service node is bound to a context, then it is only 202 available for a virtual network (VN) associated with that 203 context. 205 A services topology description requires the following 206 information: 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 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 . For each service node, the following information is 230 required: 232 o Supported service type (e.g., NAT, FW). A node 233 may support multiple service types. 235 o Number of virtual contexts that can be 236 supported. This parameter will indicate the maximum 237 number of contexts that can be created on the 238 service node. 240 o Number of virtual contexts (e.g., VRFs) available. 242 o Supported context type (e.g., VRF). 244 o Customer ID if the service node is dedicated to 245 a customer. This indicates who can use this 246 service node. 248 o List of supported (customer ID, virtual contexts). 249 Note that one context per customer is 250 a degenerate case. This will be the global 251 context for a given customer on a service node. 253 . For each service node, virtual context and service type, 254 the following information may be specified, depending on 255 the service resource requirement. That is, some of the 256 information listed here may not be relevant for some 257 services. 259 o Service bandwidth capacity 261 - Supported Packet rate 263 - Supported Bandwidth (e,g, kbps) 265 o IP Forwarding Information Base size per address family 267 o Routing Information Base size 269 o MAC Forwarding database size 271 o Number of 64-bit statistics counters for policy-based 272 accounting 274 o Number of supported Access lists (ACLs) per type 275 (e.g., number of bits per ACL, and ACL type if 276 applicable). 278 o Number of supported flows for services that require it 279 (e.g., Firewall, NAT, stateful load-balancing, Deep 280 Packet Inspection (DPI)) per flow type (i.e., fields 281 identifying a flow) or flow identification key size. 282 For systems that allow flexible memory usage across 283 flow types and/or key sizes, it is sufficient to track 284 available memory allocated for flows. 286 In addition to the services topology, it is important to have a 287 view of the Virtual Network (VN) topology (VNT) and access 288 points to which a services topology applies. The topology of 289 such a VN could be relatively static, but it may also be 290 dynamic, especially in a cloud environment where compute, 291 storage, applications and associated networks may be created 292 and removed over a short time scale. The description of a VN 293 topology encompassing the access points is important in order 294 to enable installation of policies for service chaining at the 295 right access points, instantiate the services if needed, and 296 perform the necessary monitoring as described in later 297 sections. VN topology information requirements are described in 298 [i2rs-topology-reqts], but they need to be augmented with the 299 following information: 301 . Access ports (systems and ports) per VN. A port may be 302 physical or logical on a physical port. 304 . Addresses reachable on an access port. 306 3.2. Monitoring Information 308 Service chaining requires the ability to monitor the state of 309 each service node, including liveliness and resource 310 utilization. If a service node failure is detected, an action 311 may be taken to create another service node and steer traffic 312 to it. If a service node is hitting a resource utilization 313 threshold, traffic may be directed to other service nodes, 314 and/or additional service nodes may be created. 316 The following is a set of parameters that needs be monitored 317 per service node per virtual context, and per service type as 318 applicable. It should be noted that some services may not 319 require all the parameters listed here to be monitored. 321 . Bandwidth utilization (e.g., kbps) 323 . Packet rate utilization 325 . Bandwidth utilization per CoS (e.g., kbps) 327 . Packet rate utilization per Cos 329 . Memory utilization and available memory 331 . RIB utilization per address family 333 . FIB utilization per address family 335 . Flow resource utilization per flow type 337 . CPU utilization as applicable 339 . Available storage 341 The following is a set of parameters that needs to be monitored 342 globally per physical system (e.g., host server) providing 343 services or hosting service nodes. Note that some parameters may 344 not be needed for some services: 346 . Bandwidth utilization (e.g., in kbps) 348 . Packet rate utilization 350 . Bandwidth utilization per Class of Service (CoS) 352 . Packet rate per CoS 354 . Memory utilization and available Memory 356 . RIB utilization and available RIB memory if applicable 357 per 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 system 371 hosting a service node, and/or service node as applicable. In 372 addition, a mechanism to monitor the liveliness of a service node 373 must be available. For some use cases, liveliness and resource 374 utilization information needs to be accessible to a 375 management/control plane that provides for creation of service 376 nodes and orchestration of service chains. Some of this 377 information may also be maintained in the management/orchestration 378 system and validated with the distributed system where the 379 services are instantiated. For some other use cases, a service 380 node and/or hosting system may need to be programmed to update a 381 management system with that information periodically or when a 382 configured high watermark or low watermark is reached for a 383 parameter. Thus, the interface to the service nodes and/or hosting 384 systems must provide a mechanism that enables a management/control 385 system to pull resource utilization information from these nodes 386 and systems, and for these nodes and system to send updates on 387 resource utilization to a designated system. 389 3.3. Traffic Redirection, Forwarding and Service Chaining 391 In a service chain, it is important to be able to direct 392 traffic from one service node to another. Some solutions may 393 provide this capability via dynamic routing, data-plane based 394 policy-based routing, source based routing or a combination. 395 Traffic redirection to a service chain requires the ability to 396 program the routing system with a classification rule that 397 identifies a packet/flow and an associated action that directs 398 the corresponding packet(s) to the first node in the service 399 chain. The focus in this section is on a hop-by-hop policy- 400 based routing (PBR) and source based service routing. At the 401 redirection point, classification rules should support the 402 following information that encompasses Layer1-7 information, 403 any of which may be wild-carded or left unspecified for a 404 particular case: 406 . Port 408 . VLAN/VLAN stack 410 . MAC source address 412 . MAC destination address 414 . Host/subnet Source IP address 416 . Host/subnet Destination IP address 418 . IP version 420 . IP protocol 422 . Source port/port-range 424 . Destination port/port-range 426 . Optionally, application-layer information such as key 427 words in a URI, content type or user agent 429 As a result of the classification, an action will need to be 430 specified to direct the matching packet to a service node, or 431 to perform other forwarding action(s). Thus, the following 432 actions should be supported: 434 . Forward to a specified Outgoing port (physical or 435 logical): 437 o VLAN ID 439 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 to an IP destination 451 . Lookup up in the FIB. This could be the default behavior at 452 the tail end of a chain or the result of no match. 454 . Forward the packet to a specific system that is multiple 455 IP hops away (Layer 3 PBR). The destination system IP 456 address must be specified along with the tunneling type. 457 The action must result in encapsulating the packet to 458 the destination. At the destination, a policy must be 459 installed to apply a service in a specific context to 460 the arriving packet, or direct the traffic to a local 461 service node. 463 . Insert a source route header in the transmitted packet 464 that identifies the nodes along the service path. The 465 service route may be composed of IPv4 routes, IPv6 466 routes and/or a stack of MPLS labels. The source route 467 may capitalize on existing mechanism or new mechanisms 468 that are outside the scope of this document. At the 469 destination, a policy must be installed to apply a 470 service in a specific context to the arriving packet, or 471 direct the traffic to a local service node. 473 . Insert a source route+service header that identifies the 474 service path and the service type to be applied at each 475 node. This will require the definition of a new header 476 that carries such information. 478 The number of classification rules and associated actions, 479 as well as the rate of programmability/removal of these 480 rules will be highly application dependent. When the 481 service chain is based on static policy (e.g., applied to 483 a port, a source subnet, a VN), these rules will be programmed 484 on a system at the rate of provisioning. When the attributes of 485 the policies are relatively static (e.g., applied to a fixed 486 port in fixed wireline access), the rate of provisioning on the 487 forwarding system could be low, on the order of few hundred per 488 day. When the attributes are more dynamic, such as in a mobile 489 environment on a system handling a large number of users, that 490 rate could be much higher. In a cloud environment where tenant 491 systems may be spun up and removed on a relatively short time 492 scale this rate could be on the order of few hundreds to 493 thousands a minute at a DC GW for instance. In all cases, if 494 the state is not kept in a persistent storage on the forwarding 495 system(s), system reboot actions will trigger the need for a 496 high provisioning rate, on the order at few thousands per 497 second. When policies are triggered by data-plane, the rate of 498 policy provisioning will be on the order of flow rates and 499 removal will be dependent on the flow duration. These rates 500 will be highly dependent on the applications as well, but at 501 a system that is handling a large number of flows, the protocol 502 used in provisioning must be very efficient to handle a very 503 large number of flows. 505 4. Service Chaining via BGP-based Redirection 507 BGP-based steering of a traffic flow to a first service point 508 may be required in certain cases. In this case, a router 509 hosting a service node or connected to a service node will 510 advertise a flow specification that causes a system that 511 receives the advertisement to redirect a packet or mirror a 512 copy of the packet that matches the flow specification to the 513 advertising route [BGP-flowspec]. An I2RS interface to the 514 advertising system from a control plane can help provisioning 515 the advertising router with the appropriate BGP policy as well 516 as install on that router a forwarding policy that directs the 517 packet when received to the appropriate service node. Such BGP 518 advertisements can be chained to effect the chaining of 519 multiple services. 521 5. Operational Considerations 523 6. IANA Considerations 525 There is no IANA action required by this document. 527 7. Security Considerations 529 Service chaining imposes several security issues that must be 530 addressed. First, the control system that installs policies in 531 the forwarding plane must be trusted by the forwarding plane 532 entity. An untrusted control system may install policies that 533 hijack traffic, cause denial of service, or mirror traffic to 534 an untrusted entity for eavesdropping. Thus, the communication 535 channel between a control system and a forwarding plane entity 536 must be authenticated, and may be encrypted. In addition, when 537 services are being offered to multiple VPN customers with 538 overlapping IP addresses, it is important that the customer 539 privacy is maintained when applying a service chain to a 540 customer packet/flow. Thus, the ability to identify the context 541 in which a service needs to be applied is important. In 542 addition, policies must be installed in the appropriate 543 context. Finally, congesting a service node can result in 544 packet drops that effectively may result in a denial of 545 service. Thus, obtaining information about the performance of a 546 service node is important to detect overload conditions and 547 take corrective action. 549 8. Acknowledgements 550 The authors are thankful to David Allan for his valuable input 551 and comments. 553 9. References 555 9.1. Normative References 557 [i2rs-prob] Atlas, A., Nadeau, T., and Ward, D., "Interface to the 558 Routing System Problem Statement", draft-atlas-i2rs-problem- 559 statement-01, July 2013. Work in progress. 561 [i2rs-topology-reqts] Medved, J., et al., "Topology API 562 Requirements", draft-medved-i2rs-topology-requirements-00, February 563 2013. Work in progress. 565 [BGP-flowspec] Uttaro, J., et al., "BGP Flow-Spec Extended 566 Community for Traffic Redirect to IP Next Hop", 567 draft-simpson-idr-flowspec-redirect-02, November 2012. Work in 568 progress. 570 9.2. Informative References 572 Authors' Addresses 574 Nabil Bitar 575 Verizon 576 60 Sylvan Rd. 577 Waltham, MA 02145 578 EMail: nabil.n.bitar@verizon.com 580 Giles Heron 581 Cisco Systems 582 EMail: giheron@cisco.com 584 Luyuan Fang 585 Cisco Systems 586 111 Wood Avenue South 587 Iselin, NJ 08830 588 EMail: lufang@cisco.com 590 Ram Krishnan 591 Brocade Communications 592 San Jose, CA 95134 593 EMail: ramk@brocade.com 595 Nicolai Leymann 596 Deutsche Telekom 597 Winterfeldtstrasse 21-27 598 10781 Berlin 599 Germany 600 EMail: n.leymann@telekom.de 602 Himanshu Shah 603 Ciena 604 EMail: hshah@ciena.com 606 Samita Chakrabatri 607 Ericsson 608 EMail: samita.chakrabarti@ericsson.com 609 Wassim Haddad 610 Ericsson 611 EMail: wassim.haddad@ericsson.com