idnits 2.17.1 draft-hares-dunbar-i2rs-sfc-policy-im-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 16 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 4, 2014) is 3585 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: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 536, but no explicit reference was found in the text == Unused Reference: 'I-D.medved-i2rs-topology-requirements' is defined on line 568, but no explicit reference was found in the text == Unused Reference: 'I-D.white-i2rs-use-case' is defined on line 574, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-i2rs-architecture-04 == Outdated reference: A later version (-03) exists of draft-hares-i2rs-info-model-policy-02 == Outdated reference: A later version (-03) exists of draft-hares-i2rs-info-model-service-topo-00 == Outdated reference: A later version (-17) exists of draft-ietf-i2rs-rib-info-model-03 == Outdated reference: A later version (-13) exists of draft-ietf-sfc-problem-statement-07 == Outdated reference: A later version (-06) exists of draft-white-i2rs-use-case-05 Summary: 1 error (**), 0 flaws (~~), 12 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 I2RS Working Group S. Hares 3 Internet-Draft L. Dunbar 4 Intended status: Informational Huawei 5 Expires: January 5, 2015 July 4, 2014 7 An Information Model for Service Chaining Policy 8 draft-hares-dunbar-i2rs-sfc-policy-im-01 10 Abstract 12 This draft describes an I2RS information model for managing the 13 service chain steering policy rules to a router via the I2RS 14 interface (SFC-Policy IM). 16 Status of This Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current Internet- 24 Drafts is at http://datatracker.ietf.org/drafts/current/. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 This Internet-Draft will expire on January 5, 2015. 33 Copyright Notice 35 Copyright (c) 2014 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 This document may contain material from IETF Documents or IETF 49 Contributions published or made publicly available before November 50 10, 2008. The person(s) controlling the copyright in some of this 51 material may not have granted the IETF Trust the right to allow 52 modifications of such material outside the IETF Standards Process. 53 Without obtaining an adequate license from the person(s) controlling 54 the copyright in such materials, this document may not be modified 55 outside the IETF Standards Process, and derivative works of it may 56 not be created outside the IETF Standards Process, except to format 57 it for publication as an RFC or to translate it into languages other 58 than English. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 63 2. Definition of terms . . . . . . . . . . . . . . . . . . . . . 2 64 3. Service Chaining Background . . . . . . . . . . . . . . . . . 4 65 4. Overview of information model for Service Chain . . . . . . . 4 66 5. Requirements for Service Function Forwarder Node (SFFN) 67 Resources SFC Flow Filtering . . . . . . . . . . . . . . . . 5 68 6. Service Forwarder Node RBNF . . . . . . . . . . . . . . . . . 7 69 7. Information Model for Service Chain Function Instance 70 Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 8. Information Model for Interested Service Function Instances . 9 72 9. SFFN Instances Addresses . . . . . . . . . . . . . . . . . . 10 73 10. Information Model for Reporting Directly Attached Instances . 10 74 11. RBNF for Reporting Directly Attached Instances . . . . . . . 10 75 12. Information Model for Traffic steering rules . . . . . . . . 11 76 13. Traffic Steering Rules RBNF . . . . . . . . . . . . . . . . . 11 77 14. Security Considerations . . . . . . . . . . . . . . . . . . . 12 78 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 79 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 80 17. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 81 17.1. Normative References . . . . . . . . . . . . . . . . . . 13 82 17.2. Informative References . . . . . . . . . . . . . . . . . 13 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 14 85 1. Introduction 87 This draft describes an I2RS information model for managing the 88 Service Chain via the I2RS interface. 90 2. Definition of terms 92 NFV: Network Function Virtualization 94 [NFV-Terminology]. 96 SF: Service Function 98 [I-D.ietf-sfc-problem-statement]. 100 SFF: Service Function Forwarder 102 Service Chain 104 [I-D.bitar-i2rs-service-chaining] defines a service chain as an 105 ordered set of services applied to a packet of flow. An example 106 of this is a sequence of service function such as Chain#1 {s1, s4, 107 s6} or Chain#2{s4, s7} at functional level. Also see the 108 definition of Service Function Chain in 109 [I-D.bitar-i2rs-service-chaining] 111 Service Chain Instance Path 113 The actual Service Function Instance Components selected for a 114 service chain. 116 SFFN: Service Function Forwarder Node 118 [I-D.bitar-i2rs-service-chaining]states service function can run: 119 a) natively within a router (or routing system), b) on a virtual 120 machine on a server or service engine, or in a dedicated 121 standalone hardware appliance. 123 VNF: Virtualized Network Function 125 [NFV-Terminology] 127 STOPO 129 Service topology is a topology of Service nodes (SFF). 131 SFFaddr: Service Node Address 133 [I-D.ietf-sfc-problem-statement] states this address should be IP 134 Address, or tuple of (SFFaddr, host system IP address) or tuple of 135 (host system IP address, system internal ID for service engine). 137 Service Type 139 [I-D.ietf-sfc-problem-statement]. 141 3. Service Chaining Background 143 |1 ----- |n |21 ---- |2m 144 +---+---+ +---+---+ +-+---+ +--+-----+ 145 | SF#1 | |SF#n | |SF#i1| |SF#im | 146 | | | | | | | | 147 +---+---+ +---+---+ +--+--+ +--+--+--+ 148 : : : : : 149 : : : : : 150 \ / \ / 151 +--------------+ +--------+ +---------+ 152 -- >| Chain | | SFF | ------ | SFF | ----> 153 |classifier | |Node-1 | | Node-i | 154 +--------------+ +----+---+ +----+--+-+ 155 \ | / 156 \ | SFC Encapsulation / 157 \ | / 158 ,. ......................................._ 159 ,-' `-. 160 / `. 161 | Network | 162 `. / 163 `.__.................................. _,-' 165 Figure 1 Framework of Service Chain 167 4. Overview of information model for Service Chain 169 There are three major categories of information models for Service 170 Chain management: 172 1) Service function instances discovery; 174 2) Traffic flow steering rules on a router for specific service 175 chain. 177 3) Service Chain path computatino 179 This document focuses on the first (service function instance 180 discovery), and the second (the traffic flow steering rules) as 181 expressed in I2RS policies. The third category, the Service Chain 182 path computation, is out of scope for this document. An I2RS 183 information model for Service Topology with its Traffic Engineering 184 Databased (TED) and associated inventory can be found in 185 [I-D.hares-i2rs-info-model-service-topo]. Additional I2RS modes on 186 basic network policy (BNP IM) and Policy based Routing (PBR IM) is 187 contained in [I-D.hares-i2rs-info-model-policy]. 189 5. Requirements for Service Function Forwarder Node (SFFN) Resources 190 SFC Flow Filtering 192 This section reviews the requirements for SFC Flow Filtering Policies 193 for an existing service for SFFNs within the SFC domain. 195 Inherent in the [I-D.ietf-sfc-problem-statement] is the need for 196 policies that establish and filter data flow on the Service chain 197 pathways. This document defines an I2RS model to interface to the 198 SFC's Service Function Forwarder (SFF) to install or change the the 199 Policy controlling data flow to their designated and service 200 functions and subsequent SFFN. 202 The SFC use case [I-D.bitar-i2rs-service-chaining] suggests SFF 203 resources that must be on each SFF Node (SFFN). The SFFN resources 204 include the following elements that the I2RS Client-I2RS Agent 205 protocol can utilize: 207 SFC-Use-REQ01:Address (R) 209 has the following address requirements: 211 * IP address 213 * service-node tuple (service node IP address, Host system 214 address) 216 * host-node tuple (hosting system IP-address, system internal 217 identifier) 219 SFC-Use-REQ02:Supported Service Types (R/W) SHOULD include: 221 NAT, IP Firewall, Load balancer, DPI, and others. Note that the 222 current SFC WG suggest that the SFF does not need to know the SFFN 223 type to steer the data to their designated service function. 224 Therefore, this parameter has been given "a forwarding" function 225 value. 227 SFC-Use-REQ03:Virtual contexts (R/W)SHOULD include: 229 * Maximum Number of virtual contexts supported 231 * Current number of virtual contexts in use 233 * Number of virtual contexts available 234 * Supported Context (VRF) 236 SFC-Use-REQ04: Customers currently on node (R) 238 SFC-Use-REQ05: Customer Support Table (per customer ID) (R) 240 with the following contents per entry: 242 * Customer-id 244 * List of supported Virtual Contexts 246 SFC-Use-REQ06: Service Resource Table (R/W) 248 which includes: 250 * index: Comprised of service node, virtual context, service type 252 * service bandwidth capacity 254 * supported packet rate (packets/second) 256 * supported bandwidth (kps) 258 * IP Forwarding support: specified as routing-instance(s), RIBs, 259 Address-families supported 261 * Maximum RIB-size 263 * Maximum Forward Data Base size 265 * Maximum Number of 64 bit statistics counters for policy 266 accounting 268 * Maximum number of supported flows for services 270 SFC-Use-REQ07: Virtual Network Topology (VNT) (R) 272 which includes: 274 * number of access points to which service topology applies 276 * topology of access points 278 6. Service Forwarder Node RBNF 280 ::= /*SFC-Use-REQ01 */ 281 [] /*SFC-Use-REQ02 */ 282 [] /*SFC-Use-REQ03 */ 283 [] /*SFC-Use-REQ04 */ 284 [] /*SFC-Use-REQ05 */ 285 [] /*SFC-Use-REQ06 */ 286 [] /*SFC-Use-07*/ 288 ::== 290 ::= 291 | [ ( 292 )] 293 | [ ( 294 )] 296 ::= 297 ::= 298 ::= 299 ::= INTEGER-64; 301 /* SFC-Use-02 */ 302 ::= 304 /* These are the types specified by the SFC-REQ-02] 305 ::= [] 306 [] 307 [] 308 [] 309 /* SFC-Use-03 */ ... 310 ::== 311 312 313 315 /*SFC-Use-04 */ 316 ::= INTEGER; 318 /* SFC-Use-05: Customer Support Table per Customer ID */ 319 ::= [ ::= 322 323 325 ::= 327 /*SFC-Use-REQ06 */ 328 ::= 329 330 331 332 333 334 335 336 338 := 339 340 342 /*SFC-Use-REQ07 343 * SFC_topology is defined by 344 * ietf-hares-i2rs-service-topology 345 * which includes node code 346 */ 347 ::= 349 7. Information Model for Service Chain Function Instance Discovery 351 A Service function instance can be either attached to a router via a 352 physical interface or instantiated on a virtual machine that is 353 attached to a router. Following are our assumptions: 355 1) The Service Chain Manager can get all the IP addresses or IP 356 prefix of the service function instances needed from a database or 357 provisioning system, and passed to the relevant routers. The 358 Routers can send ARP/ND broadcast/multicast messages to all the 359 attached nodes. 361 2) Service function instances will respond to ARP (IPv4)/ND (IPv6) 362 requests from its L2/L3 boundary router. 364 Service Chain Manager/Controller 365 ^ | 366 | | A: Set filter for 367 B: | | the interested service 368 Router reports the | | function instances 369 Directly attached | | 370 Service Function | | 371 Instances | V 372 +------+---+-------------+ 373 | Router | 374 ++-----+----------+------+ 375 / | | \ 376 / | | \ 377 +-+-+ +-+-+ +-+-+ +-+-+ 378 | |... | | | | ... | | 379 +---+ +---+ +---+ +---+ Server racks 380 | |... | | | | ... | | for hosting 381 +---+ +---+ +---+ +---+ Service 382 | |... | | | | ... | | Function 383 +---+ +---+ +---+ +---+ Instances 385 Figure 1: Service Function Instances 387 8. Information Model for Interested Service Function Instances 389 Service Function Instances placement can be managed by entities that 390 are not integrated with Service Chain Manager. Therefore, it is 391 necessary for the Service Chain Manager to discover all the Service 392 Function Instances that might be needed for a specific service chain. 393 Service Chain Manager can send down the filter periodically or on- 394 demand (i.e. when there is a request for building a specific service 395 chain for a client). 397 Some service function instances are attached to router via tunnels, 398 e.g. VxLAN. Service Function Instances might be partitioned by 399 clients, which are differentiated by different network ID (e.g. 400 VNID, VPN ID, etc). Some filter will carry the network ID (tenant 401 ID, or VPN ID) to get specific service functions. 403 The I2RS Client can operate as the service chain manager/controller 404 communicating with the I2RS Agents operating in the router or I2RS 405 Agents operating on the service function instances in the server 406 racks to discover and control specific service function instances. 408 The I2RS Client-Agent must be able to discover the I2RS Agent 409 associated with a specific Service Function instance by querying for: 410 SFFN Address,SFFN type, or SFFN virtual context or SFFN Customer; 412 9. SFFN Instances Addresses 414 ::= 415 [|] 416 [] 418 ::= (( 419 |) ...) 420 ::= 421 = (( 422 |) ...) 423 ::= 425 ::= 426 427 ::= 428 | 429 | 431 ::= ( ) 432 | ( ) 433 | ( ) 435 10. Information Model for Reporting Directly Attached Instances 437 When a router receives the filter of the interested Service Function 438 Instances, it can scan through all its interfaces to check if any of 439 the addresses in the filter list are attached to the interfaces. For 440 the Service Function Instances attached via Layer 2, the router can 441 send ARP/ND to get the matching instances to respond. For the 442 Service Function Instances attached via Layer 3, the router can use 443 Ping to check if the addresses in the filter are attached. 445 The response should be grouped by 447 11. RBNF for Reporting Directly Attached Instances 449 ::= 450 < SF-FILTER-NAME> 451 [ 452 | 453 |]] 455 12. Information Model for Traffic steering rules 457 The semantics of traffic steering rules is "Match" and "Action", 458 similar to the "route" described in [I-D.ietf-i2rs-rib-info-model]. 459 However, there are more matching criteria for traffic steering rules. 461 match 462 | 463 | 464 +-------+-------+-------+--------+-------+-----------+----- 465 | | | | | | | 466 | | | | | | | 467 IPv4 IPv6 tunnel MAC VLAN VxLAN ID Interface 468 (Unicast/Multicast SAFI) 470 The steering rules include matches on combinations of: 472 o Addresses: IP addresses (IPv4/IPv6), Multicast IP addresses, MAC 473 Addresses; 475 o Label fields: MPLS labels, VLAN-IDs, GRE-Keys 477 o interfaces 479 o Layer 4 fields 481 o packet sizes 483 13. Traffic Steering Rules RBNF 484 ::= 486 ::= 487 ::=
488 |