idnits 2.17.1 draft-ww-sfc-control-plane-06.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (June 8, 2015) is 3245 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'I-D.ietf-i2rs-rib-info-model' is mentioned on line 1074, but not defined == Outdated reference: A later version (-11) exists of draft-ietf-sfc-architecture-09 == Outdated reference: A later version (-06) exists of draft-ietf-sfc-dc-use-cases-02 == Outdated reference: A later version (-09) exists of draft-ietf-sfc-use-case-mobility-03 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Service Function Chaining (sfc) H. Li 3 Internet-Draft Q. Wu 4 Intended status: Informational O. Huang 5 Expires: December 10, 2015 Huawei 6 M. Boucadair, Ed. 7 C. Jacquenet 8 France Telecom 9 W. Haeffner 10 Vodafone 11 S. Lee 12 ETRI 13 R. Parker 14 Affirmed Networks 15 L. Dunbar 16 A. Malis 17 Huawei Technologies 18 J. Halpern 19 Ericsson 20 T. Reddy 21 P. Patil 22 Cisco 23 June 8, 2015 25 Service Function Chaining (SFC) Control Plane Components & Requirements 26 draft-ww-sfc-control-plane-06 28 Abstract 30 This document describes requirements for conveying information 31 between Service Function Chaining (SFC) control elements (including 32 management components) and SFC functional elements. Also, this 33 document identifies a set of control interfaces to interact with SFC- 34 aware elements to establish, maintain or recover service function 35 chains. This document does not specify protocols nor extensions to 36 existing protocols. 38 This document exclusively focuses on SFC deployments that are under 39 the responsibility of a single administrative entity. Inter-domain 40 considerations are out of scope. 42 Status of This Memo 44 This Internet-Draft is submitted in full conformance with the 45 provisions of BCP 78 and BCP 79. 47 Internet-Drafts are working documents of the Internet Engineering 48 Task Force (IETF). Note that other groups may also distribute 49 working documents as Internet-Drafts. The list of current Internet- 50 Drafts is at http://datatracker.ietf.org/drafts/current/. 52 Internet-Drafts are draft documents valid for a maximum of six months 53 and may be updated, replaced, or obsoleted by other documents at any 54 time. It is inappropriate to use Internet-Drafts as reference 55 material or to cite them other than as "work in progress." 57 This Internet-Draft will expire on December 10, 2015. 59 Copyright Notice 61 Copyright (c) 2015 IETF Trust and the persons identified as the 62 document authors. All rights reserved. 64 This document is subject to BCP 78 and the IETF Trust's Legal 65 Provisions Relating to IETF Documents 66 (http://trustee.ietf.org/license-info) in effect on the date of 67 publication of this document. Please review these documents 68 carefully, as they describe your rights and restrictions with respect 69 to this document. Code Components extracted from this document must 70 include Simplified BSD License text as described in Section 4.e of 71 the Trust Legal Provisions and are provided without warranty as 72 described in the Simplified BSD License. 74 Table of Contents 76 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 77 1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4 78 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 79 1.3. Assumptions . . . . . . . . . . . . . . . . . . . . . . . 5 80 2. Generic Considerations . . . . . . . . . . . . . . . . . . . 6 81 2.1. Generic Requirements . . . . . . . . . . . . . . . . . . 6 82 2.2. SFC Control Plane Bootstrapping . . . . . . . . . . . . . 6 83 2.3. Coherent Setup of an SFC-enabled Domain . . . . . . . . . 7 84 3. SFC Control Plane Components & Interfaces . . . . . . . . . . 8 85 3.1. Reference Architecture . . . . . . . . . . . . . . . . . 8 86 3.2. Centralized vs. Distributed . . . . . . . . . . . . . . . 9 87 3.3. Interface Reference Points . . . . . . . . . . . . . . . 10 88 3.3.1. C1: Interface between SFC Control Plane & SFC 89 Classifier . . . . . . . . . . . . . . . . . . . . . 10 90 3.3.2. C2: Interface between SFC Control Plane & SFF . . . . 12 91 3.3.3. C3: Interface between SFC Control Plane & SFC-aware 92 SFs . . . . . . . . . . . . . . . . . . . . . . . . . 12 93 3.3.4. C4: Interface between SFC Control Plane & SFC Proxy . 13 94 4. Additional Considerations . . . . . . . . . . . . . . . . . . 14 95 4.1. Discovery of the SFC Control Element . . . . . . . . . . 14 96 4.2. SF Symmetry . . . . . . . . . . . . . . . . . . . . . . . 14 97 4.3. Pre-deploying SFCs . . . . . . . . . . . . . . . . . . . 14 98 4.4. Withraw a Service Function (SF) . . . . . . . . . . . . . 14 99 4.5. SFC/SFP Operations . . . . . . . . . . . . . . . . . . . 15 100 4.6. Unsolicited (Notification) Messages . . . . . . . . . . . 15 101 4.7. SF Liveness Detection . . . . . . . . . . . . . . . . . . 15 102 4.8. Monitoring & Counters . . . . . . . . . . . . . . . . . . 16 103 4.9. SFC/SFP Diagnosis . . . . . . . . . . . . . . . . . . . . 16 104 4.10. Validity Lifetime . . . . . . . . . . . . . . . . . . . . 17 105 4.11. Considerations Specific to the Centralized Path 106 Computation Model . . . . . . . . . . . . . . . . . . . . 17 107 4.11.1. Service Function Path Adjustment . . . . . . . . . . 17 108 4.11.2. Head End Initiated SFP Establishment . . . . . . . . 18 109 4.11.3. (Regional) Restoration of Service Functions . . . . 18 110 5. Security Considerations . . . . . . . . . . . . . . . . . . . 19 111 5.1. Secure Communications . . . . . . . . . . . . . . . . . . 19 112 5.2. Pervasive Monitoring . . . . . . . . . . . . . . . . . . 20 113 5.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 20 114 5.4. Denial-of-Service (DoS) . . . . . . . . . . . . . . . . . 20 115 5.5. Illegitimate Discovery of SFs and SFC Control Elements . 20 116 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 117 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 118 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 119 8.1. Normative References . . . . . . . . . . . . . . . . . . 21 120 8.2. Informative References . . . . . . . . . . . . . . . . . 21 121 Appendix A. RSP-related Considerations . . . . . . . . . . . . . 23 122 A.1. Encoding the Exact SFF-SF-sequence in Data Packets . . . 23 123 A.2. Fully Controlled SFF-SF-Sequence for a SFP . . . . . . . 23 124 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24 126 1. Introduction 128 The dynamic enforcement of a service-derived forwarding policy for 129 packets entering a network that supports advanced Service Functions 130 (SFs) has become a key challenge for operators. Typically, many 131 advanced Service Functions (e.g., Performance Enhancement Proxies 132 ([RFC3135]), NATs [RFC3022][RFC6333][RFC6146], firewalls 133 [I-D.ietf-opsawg-firewalls], etc.) are solicited for the delivery of 134 value-added services, particularly to meet various service objectives 135 such as IP address sharing, avoiding covert channels, detecting and 136 protecting against ever increasing Denial-of-Service (DoS) attacks, 137 etc. 139 Because of the proliferation of such advanced service functions 140 together with complex service deployment constraints that demand more 141 agile service delivery procedures, operators need to rationalize 142 their service delivery logics and master their complexity while 143 optimising service activation time cycles. The overall problem space 144 is described in [RFC7498]. A more in-depth discussion on use cases 145 can be found in [I-D.ietf-sfc-use-case-mobility] and 146 [I-D.ietf-sfc-dc-use-cases]. 148 [I-D.ietf-sfc-architecture] presents a model addressing the 149 problematic aspects of existing service deployments, including 150 topological dependence and configuration complexity. It also 151 describes an architecture for the specification, creation, and 152 ongoing maintenance of Service Function Chains (SFC) within a 153 network. That is, how to define an ordered set of Service Functions 154 and ordering constraints that must be applied to packets and/or 155 frames and/or flows selected as a result of classification. 157 1.1. Scope 159 While [I-D.ietf-sfc-architecture] focuses on data plane 160 considerations, this document describes requirements for conveying 161 information between SFC control elements (including management 162 components) and SFC functional elements. Also, this document 163 identifies a set of control interfaces to interact with SFC-aware 164 elements to establish, maintain or recover service function chains. 166 Both distributed and centralized control plane schemes to install 167 SFC-related state and influence forwarding policies are discussed. 169 This document does not make any assumption on the deployment use 170 cases. In particular, the document implicitly covers fixed, mobile, 171 data center networks and any combination thereof. 173 This document does not make any assumption about which control 174 protocol to use, whether one or multiple control protocols are 175 required, or whether the same or distinct control protocols will be 176 invoked for each of the control interfaces. It is out of scope of 177 this document to specify a profile for an existing protocol, to 178 define protocol extensions, or to select a protocol. 180 Considerations related to the chaining of Service Functions that span 181 domains owned by multiple administrative entities are out of scope. 183 It is out of scope of this document to discuss SF-specific control 184 and policy enforcement schemes; only SFC considerations are 185 elaborated, regardless of the various connectivity services that may 186 be supported in the SFC domain. Likewise, only the control of SFC- 187 aware elements is discussed. 189 Service catalogue (including guidelines for deriving service function 190 chains) is out of scope. 192 1.2. Terminology 194 The reader should be familiar with the terms defined in [RFC7498] and 195 [I-D.ietf-sfc-architecture]. 197 The document makes use of the following terms: 199 o SFC data plane functional element: Refers to SFC-aware Service 200 Function, Service Function Forwarder (SFF), SFC Proxy, or SFC 201 Classifier as defined in the SFC data plane architecture 202 [I-D.ietf-sfc-architecture]. 204 o SFC Control Element: A logical entity that instructs one or more 205 SFC data plane functional elements on how to process packets 206 within an SFC-enabled domain. 208 o SFC Classification entry: Refers to an entry maintained by an SFC 209 Classifier that reflects the policies for binding an incoming 210 flow/packet to a given SFC. Actions are associated with matching 211 criteria. For example, packets can be marked with the appropriate 212 SFC-related information to differentiate flows so that subsequent 213 SFFs can forward the flows to a sequence of SFs in a given order. 214 The set of classification entries maintained by a Classifier are 215 referred to as in the classification policy table. 217 o SFC Forwarding Policy Table: this table reflects the SFC-specific 218 traffic forwarding policy enforced by SFF components for every 219 relevant incoming packet that is associated to one of the existing 220 SFCs. 222 [[Note: The question of whether the data plane operates just in 223 terms of SFP IDs or needs SFC IDs, as described in this version 224 of the draft, is still under discussion among the authors.]] 226 1.3. Assumptions 228 This document adheres to the assumptions listed in Section 1.2 of 229 [I-D.ietf-sfc-architecture]. 231 This document does not make any assumptions about the co-location of 232 SFC data plane functional elements; this is deployment-specific. 233 This document can accommodate a variety of deployment contexts such 234 as (but not limited to): 236 o A Service Function Forwarder (SFF) can connect instances of the 237 same or distinct SFs. 238 o A SF instance can be serviced by one or multiple SFFs. 239 o One or multiple SFs can be co-located with a SFF. 241 o A boundary node (that connects one SFC-enabled domain to a node 242 either located in another SFC-enabled domain or in a domain that 243 is SFC-unaware) can act as an egress node and an ingress node for 244 the same flow. 245 o Distinct ingress and egress nodes may be crossed by a packet when 246 forwarded in an SFC-enabled domain. 247 o Distinct ingress nodes may be solicited for each traffic direction 248 (e.g., upstream and downstream). 249 o An ingress node can embed a Classifier. 250 o An ingress node may not embed a Classifier, but it can be 251 responsible for dispatching flows among a set of Classifiers. 252 o The same boundary node may act as an ingress node, an egress node, 253 and also embed a Classifier. 254 o A Classifier can be hosted in a node that embeds one or more SFs. 255 o Many network elements within an SFC-enabled domain may behave as 256 egress/ingress nodes. 258 Furthermore, the following assumptions are made: 260 o A Control Element can be co-located with a Classifier, SFF or SF. 261 o One or multiple Control Elements can be deployed in an SFC-enabled 262 domain. 263 o State synchronization between Control Elements is out of scope. 265 2. Generic Considerations 267 2.1. Generic Requirements 269 For deployments that would require so, SFC forwarding must be allowed 270 even if no control protocols are enabled. Static configuration must 271 be allowed. 273 A permanent association between an SFC data plane element with a 274 Control Element must not be required; specifically, the SFC-enabled 275 domain must keep on processing incoming packets according to the SFC 276 instructions even during temporary unavailability events of control 277 plane components. SFC implementations that do not meet this 278 requirement will suffer from another flavor of the constrained high 279 availability issue, discussed in Section 2.3 of [RFC7498], supposed 280 to be solved by SFC designs. 282 2.2. SFC Control Plane Bootstrapping 284 The interface that is used to feed the SFC control plane with service 285 objectives and guidelines is not part of the SFC control plane 286 itself. Therefore, this document assumes the SFC control plane is 287 provided with a set of information that is required for proper SFC 288 operation with no specific assumption about how this information is 289 collected/provisioned, nor about the structure of such information. 290 The following information that is likely to be provided to the SFC 291 control plane at bootstrapping includes (non-exhaustive list): 293 o Locators for Classifiers/SFF/SFs/Proxies, etc. 294 o SFs serviced by each SFF. 295 o A list of service function chains, including how they are 296 structured and unambiguously identified. 297 o Status of each SFC: active/pre-deployment phase/etc. A SFC can be 298 defined at the management level and instantiated in an SFC-enabled 299 domain for pre-deployment purposes (e.g., testing). Actions to 300 activate, modify or withdraw an SFC are triggered by the control 301 plane. Nevertheless, this document does not make any assumption 302 about how an operator instructs the control plane. 303 o A list of classification guidelines and/or rules to bind flows to 304 SFCs/SFPs. 305 o Optionally, (traffic/CPU/memory) load balancing objectives at the 306 SFC level or on a per node (e.g., per-SF/SFF/Proxy) basis. 307 o Security credentials. 308 o Context information that needs to be shared on a per SFC basis. 310 Also, the SFC control plane may gather the following information from 311 an SFC-enabled domain at bootstrapping (non-exhaustive list). How 312 this information is collected is left unspecified in this document: 314 o The list of active SFC-aware SFs (including their locators). 315 o The list of SFFs and the SFs that are attached to. 316 o The list of enabled SFC Proxies, and the list of SFC-unware SFs 317 attached to. 318 o The list of active SFCs/SFPs as enabled in an SFC-enabled domain. 319 o The list of Classifiers and their locators, so as to retrieve the 320 classification policy table for each Classifier, in particular. 321 o The SFC forwarding policy tables maintained by SFFs. 323 During the bootstrapping phase, a Control Element may detect a 324 conflict between the running configuration in an SFC data plane 325 element and the information maintained by the control plane. 326 Consequently, the control plane undertakes appropriate actions to fix 327 those conflicts. This is typically achieved by invoking one of the 328 interfaces defined in Section 3.3. 330 2.3. Coherent Setup of an SFC-enabled Domain 332 Various transport encapsulation schemes and/or variations of SFC 333 header implementations may be supported by one or several nodes of an 334 SFC-enabled domain. For the sake of coherent configuration, the SFC 335 control plane is responsible for instructing all the involved SFC 336 data plane functional elements about the behavior to adopt to select 337 the transport encapsulation scheme(s), the version of the SFC header 338 to enable, etc. 340 3. SFC Control Plane Components & Interfaces 342 3.1. Reference Architecture 344 The SFC control plane is responsible for the following: 346 o Build and monitor the service-aware topology. For example, this 347 can be achieved by means of dynamic SF discovery techniques. 348 Those means are out of scope of this document. 349 o Maintain a repository of service function chains, SFC matching 350 criteria to bind flows to a given service function chain, and 351 mapping between service function chains and SFPs. 352 o Guarantee the coherency of the configuration and the operation of 353 an SFC-enabled domain. 354 o Dynamically compute a service-aware forwarding path (distributed 355 model, see Section 3.2) 356 o Determine a forwarding path in the context of a centralized 357 deployment model (see Section 3.2). 358 o Update service function chains or adjust SFPs (e.g., for 359 restoration purposes) based on various inputs (e.g., external 360 policy context, path alteration, SF unavailability, SF withdrawal, 361 service decommissioning, etc.). 362 o Populate SFC forwarding policy tables of involved SFC data plane 363 elements and provides Classifiers with traffic classification 364 rules. 366 Figure 1 shows the overall SFC control plane architecture, including 367 interface reference points. 369 This document does not elaborate on the internal decomposition of the 370 SFC Control & Management Plane functional blocks. The components 371 within the SFC Control & Management Planes and their interactions are 372 out of scope. 374 As discussed in Section 3.2, the SFC control plane can be implemented 375 in a (logically) centralized or distributed fashion. 377 +----------------------------------------------+ 378 | | 379 | SFC Control & Management Planes | 380 +-------| | 381 | | | 382 C1 +------^-----------^-------------^-------------+ 383 +---------------------|C3---------|-------------|-------------+ 384 | | +----+ | | | 385 | | | SF | |C2 |C2 | 386 | | +----+ | | | 387 | +----V--- --+ | | | | 388 | | SFC | +----+ +-|--+ +----+ | 389 | |Classifier |---->|SFF |----->|SFF |------->|SFF | | 390 | | Node |<----| |<-----| |<-------| | | 391 | +-----------+ +----+ +----+ +----+ | 392 | | | | | 393 | |C2 ------- | | 394 | | | | +-----------+ C4 | 395 | V +----+ +----+ | SFC Proxy |--> | 396 | | SF | |SF | +-----------+ | 397 | +----+ +----+ | 398 | |C3 |C3 | 399 | SFC Data Plane Components V V | 400 +-------------------------------------------------------------+ 402 Figure 1: SFC Control Plane: Overview 404 3.2. Centralized vs. Distributed 406 The SFC control plane can be (logically) centralized, distributed or 407 a combination thereof. Whether one or multiple SFC Control Elements 408 are enabled is deployment-specific. Nevertheless, the following 409 comments can be made: 411 SFC management (including SFC monitoring and supervision): is likely 412 to be centralized. 414 SFC Mapping Rules: i.e., service instructions to bind a flow to a 415 service function chain are likely to be managed by a central SFC 416 Control Element, but the resulting policies can be shared among 417 several Control Elements. Note, these policies can be 418 complemented with local information (e.g., an IPv4 address/IPv6 419 prefix assigned to a customer) because such information may not be 420 available to the central entity but known only during network 421 attachment phase. 423 Path computation: can be either distributed or centralized. 424 Distributed path computation means that the selection of the exact 425 sequence of SF functions that a packet needs to invoke (along with 426 instances and/or SFF locator information) is a result of a 427 distributed path selection algorithm executed by involved nodes. 428 For some traffic engineering proposes, the SFP may be constrained 429 by the control plane; as such, some SFPs can be fully specified 430 (i.e., list all the SFF/SFs that need to be solicited) or 431 partially specified (e.g., exclude some nodes, explicitly select 432 which instance of a given SF needs to be invoked, etc.). 434 SFC Resiliency (including restoration) refers to mechanisms to 435 ensure high available service function chains. It includes means 436 to detect node/link/path failures. Both centralized and 437 distributed mechanism to ensure SFC resiliency can be envisaged. 439 Implementing a (logically) centralized path computation engine 440 requires information to be dynamically communicated to the central 441 SFC Control Element, such as the list of available SF instances, SFF 442 locators, load status, SFP availability, etc. 444 3.3. Interface Reference Points 446 The following sub-sections describe the interfaces between the SFC 447 Control & Management Planes, as well as various SFC data plane 448 elements 450 3.3.1. C1: Interface between SFC Control Plane & SFC Classifier 452 As a reminder, a Classifier is a function that is responsible for 453 classifying traffic based on (pre-defined) rules. 455 This interface is used to install SFC classification rules in 456 Classifiers. Once classification rules are populated, SFC 457 Classifiers are responsible for binding incoming traffic to service 458 function chains according to these classification rules. Note, the 459 SFC control plane must not make any assumption on how the traffic is 460 to be bound to a given SFC. In other words, classification rules are 461 deployment-specific. For instance, classification can rely on a 462 subset of the information carried in a received packet such as 463 5-tuple classification, be subscriber-aware, be driven by traffic 464 engineering considerations, or any combination thereof. 466 The SFC control plane should be responsible for removing invalid (and 467 stale) mappings from the classification tables maintained by the 468 classifiers. Also, local sanity checks mechanisms may be supported 469 locally by the Classifiers, but those are out of scope. 471 The Classifier may be notified by the control plane about the 472 available SFs (including their locators) or be part of the service 473 function discovery procedure. 475 Classification rules may be updated, deleted or disabled by the 476 control plane. Criteria that would trigger those operations are 477 deployment-specific. 479 Given that service function chaining solutions may be applied to very 480 large sets of traffic, any control solution should take scaling 481 issues into consideration as part of the design. 483 Below are listed some functional objectives for this interface: 485 o Rationalize the management of classification rules. 486 o Maintain a global view of instantiated rules in all Classifiers in 487 an SFC-enabled domain. 488 o Check the consistency of instantiated classification rules within 489 the same Classifier or among multiple Classifier. 490 o Assess the impact of removing or modifying a classification entry 491 on packets entering an SFC-enabled domain. 492 o Aggregate classification rules for the sake of performance 493 optimization (mainly reduce lookup delays). 494 o Adjust classification rules when rules are based on volatile 495 identifiers (e.g., an IPv4 address, IPv6 prefix). 496 o Allow to rapidly restore SFC states during failure events that 497 occurred at a Classifier (or a Control Element). 499 The control plane must instruct the Classifier whether it can trust 500 an existing SFC marking of an incoming packet or whether it must be 501 ignored. 503 For bidirectional packet processing purposes (e.g., full or partial 504 path symmetry), the control plane invokes this interface to configure 505 the appropriate classification entries. 507 A Classifier can send unsolicited messages through this interface to 508 notify the SFC Control & Management Planes about specific events. 510 When re-classification is allowed in an SFC-enabled domain, this 511 interface can be used to control Classifiers co-resident with SFC- 512 aware SFs, SFC Proxies, or SFFs to manage re-classification rules . 514 SFC Classification policy entry should be bound to one single service 515 function chain (or one single SFP); when an incoming packet matches 516 more than one classification entry, tie-breaking criteria should be 517 specified (e.g., priority). Such tie-breaking criteria should be 518 instructed by the control plane. 520 The identification of instantiated SFCs/SFPs is local to each 521 administrative domain; it is policy-based and deployment-specific. 523 3.3.2. C2: Interface between SFC Control Plane & SFF 525 SFFs make traffic forwarding decisions according to the entries 526 maintained in their SFC forwarding policy table. Such table is 527 populated by the SFC control plane through the C2 interface. 529 This interface is used to instruct a SFF about the SFC-aware SFs that 530 it can service. This interface is also used by the SFF to report the 531 connectivity to their attached (including embedded) SFs. Local means 532 may be enabled between the SFC-aware SFs and SFFs to allow for the 533 dynamic attachment of SFs to a SFF and/or discovery of SFs by a SFF 534 but those means are unspecified in this document. 536 The C2 interface is also used for collecting states of attributes 537 (e.g., availability, workload, latency), for example, to dynamically 538 adjust Service Function Paths. 540 3.3.3. C3: Interface between SFC Control Plane & SFC-aware SFs 542 The SFC control plane uses this interface to interact with SFC-aware 543 SFs. 545 SFs may need to output some processing results of packets to the SFC 546 control plane. This information can be used by the SFC control plane 547 to update the SFC classification rules and the SFC forwarding policy 548 table entries. 550 This Interface is used to collect such kind of feedback information 551 from SFs. For example, the following information can be exchanged 552 between a SF and the SFC control plane: 554 o SF execution status: Some SFs may need to send information to the 555 control plane to fine tune SFPs. For example, a threat-detecting 556 SF can periodically send the threat characteristics via this 557 interface, such as high probability of threat with packet of a 558 given size. The control plane can then add an appropriate 559 matching criteria to SFF to steer traffic to a scrubbing center. 561 o SF load update: When SFs are under stress that yielded the 562 crossing of some performance thresholds, the SFC control plane 563 needs to be notified to adjust SFPs accordingly (especially when 564 the centralized path computation mode is enabled). It is out of 565 scope of this document to specify the exact methods to monitor the 566 performance threshold or stress level of SFs, nevertheless the SFC 567 control plane can invoke those methods for its operations. 569 The SFC control needs the above status information for various tasks 570 it undertakes, but this information may be acquired directly from SFs 571 or indirectly from other management and control systems in the 572 operational environment. 574 This interface is also used to instruct an SFC-aware SF about any 575 context information it needs to supply in the context of a given SFC. 577 Also, this interface informs the SFC-aware SF about the semantics of 578 a context information, which would otherwise have opaque meaning. 579 Several attributes may be associated with a context information such 580 as (but not limited to) the "scope" (e.g., per-packet, per-flow or 581 per host), whether it is "mandatory" or "optional" to process flows 582 bound to a given chain, etc. Note that a context may be mandatory 583 for "chain 1", but optional for "chain 2". 585 The control plane may indicate, for a given service function chain, 586 an order for consuming a set of contexts supplied in a packet. 588 A SFC-aware SF can also be instructed about the behavior is should 589 adopt after consuming a context information that was supplied in the 590 SFC header. For example, the context can be maintained or stripped. 591 The SFC-aware SF can be instructed to inject a new context header 592 into the SFC header. 594 Multiple SFs may be located within the same physical node, and no SFF 595 is enabled in that same node, means to unambiguously forward the 596 traffic to the appropriate SF must be supported. 598 An SF can be instructed to strip the SFC information for the chains 599 it terminates. 601 3.3.4. C4: Interface between SFC Control Plane & SFC Proxy 603 The SFC control plane uses this interface to interact with an SFC 604 Proxy. 606 The SFC proxy can be instructed about authorized SFC-unware SFs it 607 can service. A SFC Proxy can be instructed about the behavior it 608 should adopt to process the context information that was supplied in 609 the SFC header on behalf of a SFC-unware SF, e.g., the context can be 610 maintained or stripped. 612 The SFC proxy is also instructed about the semantics of a context 613 information, which would otherwise have opaque meaning. Several 614 attributes may be associated with a context information such as (but 615 not limited to) the "scope" (e.g., per-packet, per-flow or per host), 616 whether it is "mandatory" or "optional" to process flows bound to a 617 given chain, etc. 619 The SFC Proxy can also be instructed to add SF some new context 620 information into the SFC header on behalf of a SFC-unaware SF. 622 The C4 interface is also used for collecting attribute states (e.g., 623 availability, workload, latency), for example, to dynamically adjust 624 Service Function Paths. 626 4. Additional Considerations 628 4.1. Discovery of the SFC Control Element 630 SFC data plane functional elements need to be provisioned with the 631 locators of the Control Elements. This can be achieved using a 632 variety if mechanisms such as static configuration or the activation 633 of a service discovery mechanism. The exact specification of how 634 this provisioning is achieved is out of scope. 636 4.2. SF Symmetry 638 Some SFs require both directions of a flow to traverse. Some service 639 function chains require full symmetry. If a SF (e.g., stateful 640 firewall or NAT) needs both direction of a flow, it is the SF 641 instantiation that needs both direction of a flow to traverse, not 642 the abstract SF (which can have many instantiations spread across the 643 network). 645 4.3. Pre-deploying SFCs 647 Enabling service function chains should preserve some deployment 648 practices adopted by Operators. Particularly, installing a service 649 function chain (and its associated SFPs) should allow for pre- 650 deployment testing and validation purposes (that is a restricted and 651 controlled usage of such service function chain (and associated 652 SFPs)). 654 4.4. Withraw a Service Function (SF) 656 During the lifetime of a SFC, a given SF can be decommissioned. To 657 accommodate such context and any other case where a SF is to be 658 withdrawn, the control plane should instruct the SFC data plane 659 functional element about the behavior to adopt. Particularly: 661 1. a first approach would be to update the service function chains 662 (and associated SFPs) where that SF is present by removing any 663 reference to that SF. Doing so avoids to induce service failures 664 for end users. 666 2. a second approach would be to delete/deactivate any service 667 function chain (and its associated SFPs) that involves that SF 668 but install new service function chains. 670 4.5. SFC/SFP Operations 672 Various actions can be executed on a service function chain (and 673 associated SFPs) that is structured by the SFC Control & Management 674 planes. Indeed, a service function chain (and associated SFPs) can 675 be enabled, disabled, its structure modified by adding a new SF hop 676 or remove an SF from the sequence of SFs to be invoked, its 677 classification rules modified, etc. 679 A modification of a service function chain can trigger control 680 messages with the appropriate SFC-aware nodes accordingly. 682 4.6. Unsolicited (Notification) Messages 684 Involved SFC data plane functional element must be instructed to send 685 unsolicited notifications when loops are detected, a problem in the 686 structure of a service function chain is encountered, a long 687 unavailable forwarding path time is observed, etc. 689 Specific criteria to send unsolicited notifications to a Control 690 Element should be fine tuned by the control plane using the interface 691 defined in Section 3.3. 693 4.7. SF Liveness Detection 695 The control plane must allow to detect the liveliness of SFs of an 696 SFC-enabled domain. In particular, it must allow to dynamically 697 detect that a SF instance is out of service and notify the relevant 698 Control Element elements accordingly. The liveness information may 699 be acquired directly from SFs or indirectly from other management and 700 control systems in the operational environment. 702 Liveness status records for all SF instances, and service function 703 chains (including the SFPs bound to a given chain) are maintained by 704 the SFC Control & Management. 706 The Classifier may be notified by the control plane or be part of the 707 liveness detection procedure. 709 The ability of a SFC Control Element to check the liveness of each SF 710 present in service function chain has several advantages, including: 712 o Enhanced status reporting by the control & management planes 713 (i.e., an operational status for any given service chain derived 714 from liveness state of its SFs). 715 o Ability to support various resiliency policies (i.e., bypass a 716 node embedding an SF, use alternate node, use alternate chain, 717 drop traffic, etc.) . 718 o Ability to support load balancing capabilities to solicit multiple 719 SF instances that provide equivalent functions. 721 Because a node embedding a SF can be responsive from a reachability 722 standpoint (e.g., IP level) while the function its provides may be 723 broken (e.g., a NAT module may be down), additional means to assess 724 whether an SF is up and running are required. These means may be 725 service-specific. 727 4.8. Monitoring & Counters 729 SFC-specific counters and statistics must be provided using of the 730 interfaces defined in Section 3.3. These data include (but not 731 limited to): 733 o Number of flows ever and currently assigned to a given service 734 function chain and a given SFP. 735 o Number of flows, packets, bytes dropped due to policy. 736 o Number of packets and bytes in/out per service function chain. 737 o Number of flows, packets, bytes dropped due to unknown service 738 function chain (this is valid in particular for a SF node). 740 4.9. SFC/SFP Diagnosis 742 [[Note: This section is expected to be removed once the working 743 group adopts a document on OAM.]] 745 The Control & Management planes should allow for the following: 747 o Assess the status of the serviceability of a SF (i.e., the SF 748 provides the service(s) it is configured for). Obviously, this 749 assessment must not rely only on IP reachability to decide whether 750 a SF is up and running. 751 o Diagnose the availability of a SFC (including the availability of 752 a particular SFP bound to a given SFC). 753 o Retrieve the set of service function chains that are enabled 754 within a domain. 755 o Assess whether an SFC-enabled domain is appropriately configured 756 (including, check the configured chains are matching what should 757 be configured in that domain, and ensure coherent classification 758 rules are installed in and enforced by all the Classifiers of the 759 SFC-enabled domain). 761 o Correlate classification policies with observed forwarding actions 762 (including, assess the output of the classification rule applied 763 on a packet presented to a Classifier of an SFC-enabled domain). 764 o Support the correlation between a service function chain and the 765 actual forwarding path followed by a packet matching that service 766 function chain. 767 o Notify the SFC Control Element whenever some (critical) events 768 occur (for example, a malfunctioning SF instance). 769 o Re-use SF built-in diagnostic procedures specific to each SF. 771 The SFC control plane must be able to invoke SFC OAM mechanisms, and 772 to determine the results of OAM operations. 774 4.10. Validity Lifetime 776 SFC instructions communicated via the various interfaces introduced 777 in Section 3.3 may be associated with validity lifetimes, in which 778 case classification entries will be automatically removed upon the 779 expiry of the validity lifetime without requiring an explicit action 780 from a Control Element. 782 Lifetimes are used in particular by an SFC data plane element to 783 clear invalid control entries that would be maintained in the system 784 if, for some reason, no appropriate action was undertaken by the 785 control plane to clear such entries. 787 Both short and long lifetimes may be assigned. 789 4.11. Considerations Specific to the Centralized Path Computation Model 791 This section focuses on issues that are specific to the centralized 792 deployment model (Section 3.2). 794 4.11.1. Service Function Path Adjustment 796 A SFP is determined by composing SF instances and overlay links among 797 SFFs. Thus, the status of a SFP depends on the states or attributes 798 (e.g., availability, topological location, latency, workload, etc.) 799 of its components. For example, failure of a single SF instance 800 results in failure of the whole SFP. Since these states or 801 attributes of SFP components may vary in time, their changes should 802 monitored and SFPs should be dynamically adjusted. 804 Examples of use cases for SFP adjustment are listed below: 806 SFP fail-over: re-construct a SFP with replacing the failed SF 807 instance with another instance of the same SF. 809 SFP with better latency experience: re-construct a SFP with a low 810 path stretch considering the changes in topological locations of 811 SF instances and the latency induced by the (overlay) connectivity 812 among SFFs. 813 Traffic engineered SFC: re-construct SFPs to localize the traffic in 814 the network considering various TE goals such as bypass a node, 815 bypass a link, etc. These techniques may be used for planned 816 maintenance operations on a SFC-enabled domain. 817 SF/SFC Load balancing: re-construct SFPs to distribute the workload 818 among various SF instances. 820 For more details about the use cases, refer to 821 [I-D.lee-nfvrg-resource-management-service-chain]. 823 The procedures for SFP adjustment may be handled by the SFC control 824 plane as follows: 826 o Collect and monitor states and attributes of SF instances and 827 overlay links via the C2 interface (Section 3.3.2) and the C3 828 interface (Section 3.3.3). 829 o Evaluate SF instances and overlay links based on the monitoring 830 results. 831 o Select SF instances to re-determine a SFP according to the 832 evaluation results. 833 o Replace target SF instances (e.g., in a failure or overladed) with 834 newly selected ones. 835 o Enforce the updated SFP for upcoming SFC traversal to SFFs via the 836 C1 interface (Section 3.3.1) or the C2 interface (Section 3.3.2). 838 4.11.2. Head End Initiated SFP Establishment 840 In some scenarios where a SFC Control Element is not connected to all 841 SFFs in a SFC-enabled domain, the SFC control plane can send the 842 explicit SFF-SF-sequence or SF-sequence to the SFC head-end, e.g., 843 the SFC Classifier via the C1 interface (Section 3.3.1). SFC head- 844 end can use a signaling protocol to establish the SFF-SF-sequence 845 based on the SF-sequence. 847 4.11.3. (Regional) Restoration of Service Functions 849 There are situations that it might not be feasible for the Classifier 850 to be notified of the changes of SFF-sequence or SFF-SF-Sequence for 851 a given SFP because of the time taken for the notification and the 852 limited capability of the Classifiers. 854 If a SF has a large number of instantiations, it scales better if the 855 Classifier doesn't need to be notified with status of visible 856 instantiations of SFs on a SFP. 858 It might not be always feasible for the Classifier to be aware of the 859 exact SF instances selected for a given SFP due to too many instances 860 for each SF, notifications not being promptly sent to the Classifier, 861 or other reasons. This is about multiple instances of the same SF 862 attached to one SFF node; those instances can be handled by the SFF 863 via local load balancing schemes. 865 Regional restoration can take the similar approach as the global 866 restoration: choosing a regional ingress node that can take over the 867 responsibility of installing the new steering policies to the 868 involved SFFs or network nodes. Typically, the regional ingress node 869 should be: 871 o on the data path of the flow of the given SFC; 872 o in front of the relevant SFFs or network nodes that are impacted 873 by the change of the SFP; 874 o capable of encoding the detailed SFP to the Service Chain Header 875 of data packets of the identified flow; and 876 o capable of removing the detailed SFP encoding in data packets 877 after all the impacted SFFs and network nodes completed the policy 878 installation. 880 5. Security Considerations 882 5.1. Secure Communications 884 The SFC Control Elements and the participating SFC data plane 885 elements must mutually authenticate. SFC data plane elements must 886 ignore instructions received from unauthenticated SFC Control 887 Elements. The credentials details used during authentication can be 888 used by the SFC control plane to decide whether specific 889 authorization may be granted to a Service Function with regards to 890 some specific operations (e.g., authorize a given SF to access 891 specific context information). 893 In case multiple SFC data plane elements are embedded in the same 894 node, the authentication mechanism may be executed as a whole; not 895 for each instance. 897 A SFC data plane element must be able to send authenticated 898 unsolicited notifications to a SFC Control Element. 900 The communication between a Control Element and SFC data plane 901 elements must provide integrity and replay protection. 903 An SFC Control Element may instruct a Service Function to include 904 specific security token(s) that may be used to decrypt traffic 905 upstream. The security token may be supplied by the SFC control 906 plane or by an authorized Service Function (e.g., TLS proxy). The 907 exact details on how authorization is granted to a specific SF, 908 including via a control plane interface, should be specified. 910 A Service Function must by default discard any action from a SFC 911 Control Element that requires specific right privileges (e.g., access 912 to a legal intercept log, mirror the traffic, etc.). 914 5.2. Pervasive Monitoring 916 The authentication mechanism should be immune to pervasive monitoring 917 [RFC7258]. An attacker can intercept traffic by installing 918 classification rules that would lead to redirect all or part of the 919 traffic to an illegitimate network node. Means to protect against 920 attacks that would lead to install, remove, or modify classification 921 rules must be supported. 923 5.3. Privacy 925 The SFC control plane must be able to control the information that is 926 leaked outside an SFC-enabled domain. Particularly, the SFC control 927 plane must support means to preserve privacy [RFC6973]. Context 928 headers may indeed reveal privacy information (e.g., IMSI, user name, 929 user profile, location, etc.). Those headers must not be exposed 930 outside the operator's domain. Also, means to protect context 931 headers from eavesdroppers should be enforced. 933 5.4. Denial-of-Service (DoS) 935 In order to protect against denial of service that would be caused by 936 a misbehaving trusted SFC Control Element, SFC data plane elements 937 should rate limit the messages received from an SFC Control Element. 939 5.5. Illegitimate Discovery of SFs and SFC Control Elements 941 Means to defend against soliciting illegitimate SFs/SFFs that do not 942 belong to the SFC-enabled domain must be enabled. Such means must be 943 defined in service function discovery and SFC Control Element 944 discovery specification documents. 946 6. IANA Considerations 948 This document does not require any IANA actions. 950 7. Acknowledgements 952 This document is the result of merging with 953 [I-D.lee-sfc-dynamic-instantiation]. 955 The authors would like to thank Shibi Huang for providing input and 956 LAC Chidung for his review and comments that helped improve this 957 document. 959 The text about the semantic of a context information is provided by 960 Dave Dolson. 962 8. References 964 8.1. Normative References 966 [I-D.ietf-sfc-architecture] 967 Halpern, J. and C. Pignataro, "Service Function Chaining 968 (SFC) Architecture", draft-ietf-sfc-architecture-09 (work 969 in progress), June 2015. 971 8.2. Informative References 973 [I-D.ietf-opsawg-firewalls] 974 Baker, F. and P. Hoffman, "On Firewalls in Internet 975 Security", draft-ietf-opsawg-firewalls-01 (work in 976 progress), October 2012. 978 [I-D.ietf-sfc-dc-use-cases] 979 Surendra, S., Tufail, M., Majee, S., Captari, C., and S. 980 Homma, "Service Function Chaining Use Cases In Data 981 Centers", draft-ietf-sfc-dc-use-cases-02 (work in 982 progress), January 2015. 984 [I-D.ietf-sfc-use-case-mobility] 985 Haeffner, W., Napper, J., Stiemerling, M., Lopez, D., and 986 J. Uttaro, "Service Function Chaining Use Cases in Mobile 987 Networks", draft-ietf-sfc-use-case-mobility-03 (work in 988 progress), January 2015. 990 [I-D.lee-nfvrg-resource-management-service-chain] 991 Lee, S., Pack, S., Shin, M., and E. Paik, "Resource 992 Management in Service Chaining", draft-lee-nfvrg-resource- 993 management-service-chain-01 (work in progress), March 994 2015. 996 [I-D.lee-sfc-dynamic-instantiation] 997 Lee, S., Pack, S., Shin, M., and E. Paik, "SFC dynamic 998 instantiation", draft-lee-sfc-dynamic-instantiation-01 999 (work in progress), October 2014. 1001 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 1002 Address Translator (Traditional NAT)", RFC 3022, January 1003 2001. 1005 [RFC3135] Border, J., Kojo, M., Griner, J., Montenegro, G., and Z. 1006 Shelby, "Performance Enhancing Proxies Intended to 1007 Mitigate Link-Related Degradations", RFC 3135, June 2001. 1009 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 1010 NAT64: Network Address and Protocol Translation from IPv6 1011 Clients to IPv4 Servers", RFC 6146, April 2011. 1013 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 1014 Stack Lite Broadband Deployments Following IPv4 1015 Exhaustion", RFC 6333, August 2011. 1017 [RFC6973] Cooper, A., Tschofenig, H., Aboba, B., Peterson, J., 1018 Morris, J., Hansen, M., and R. Smith, "Privacy 1019 Considerations for Internet Protocols", RFC 6973, July 1020 2013. 1022 [RFC7258] Farrell, S. and H. Tschofenig, "Pervasive Monitoring Is an 1023 Attack", BCP 188, RFC 7258, May 2014. 1025 [RFC7498] Quinn, P. and T. Nadeau, "Problem Statement for Service 1026 Function Chaining", RFC 7498, April 2015. 1028 Appendix A. RSP-related Considerations 1030 This section records some contributions proposed by L. Dunbar and A. 1031 Malis, but have not been discussed yet among authors. 1033 A.1. Encoding the Exact SFF-SF-sequence in Data Packets 1035 Encoding the exact RSP in every packet has the benefit and the issues 1036 associated with source routing. This approach may not be optimal 1037 when the SFP doesn't change very frequently, as in minutes or hours. 1039 There are contexts that it might not be feasible for the head end 1040 Classifier to be notified of the changes of SFF-sequence or SFF-SF- 1041 Sequence for a given SFP because of the time taken for the 1042 notification and the limited capability of the Classifier nodes. 1044 A.2. Fully Controlled SFF-SF-Sequence for a SFP 1046 This section describes the information that can be exchanged over C2 1047 interface (Section 3.3.2) when the SFC Control Element explicitly 1048 passes the steering policies to all SFFs for the SFF-SF-Sequence of a 1049 given SFC. In this model, each SFF doesn't need to signal other SFFs 1050 for the SFP. 1052 Suppose the SFC ID for this SFP is "yellow", an example of policy to 1053 "sff-a" is depicted in Figure 2 (for illustration proposes) 1055 Matching | Action 1056 ----------------------------------------+------------------------- 1057 SFC ID = "yellow" & ingress = sffx-port | next-hop: "sf2" & VID 1058 SFC ID = "yellow" & ingress = sf2-port | next-hop: "sf3" & VID 1059 SFC ID = "yellow" & ingress = sf3-port | next-hop: sff-b 1061 Figure 2: Example of Traffic Steering Policy to a SFF node 1063 The SFF nodes may not be directly adjacent to each other. They can 1064 be interconnected by tunnels, such as GRE, VxLAN, etc. SFs are 1065 attached to a SFF node or SFC Proxy node via Ethernet link or other 1066 link types. Therefore, the steering policies to a SFF node for 1067 service function chain depends on if the packet comes from previous 1068 SFF or comes from a specific SF, i.e., the SFC Forwarding Policy 1069 Table entries have to be ingress port specific. There are multiple 1070 different steering policies for one flow within one SFF and each set 1071 of steering policies is specific for an ingress port. 1073 The semantics of traffic steering rules can be "Match" and "Action", 1074 similar to the "route" described in [I-D.ietf-i2rs-rib-info-model]. 1075 The "match" and "action" for distinct ports can be different. The 1076 matching criteria for SFF can be more sophisticated. For example, 1077 the matching criteria could be any fields in the data packets: 1079 o Ingress port 1080 o Destination MAC address 1081 o Source MAC address 1082 o VLAN_id, 1083 o Destination IP address 1084 o Source IP address 1085 o Source port number 1086 o Destination port number 1087 o DSCP 1088 o Packet size, etc., or any combination thereof. 1090 A SFF node may not support some of the matching criteria listed 1091 above. It is important that SFC control plane can retrieve the 1092 supported matching criteria by SFF nodes. The "Actions" for traffic 1093 steering could be to steer traffic to the attached service function 1094 or SF instantiations via a specific port. 1096 The "Actions" to SFC Proxy may include a method to map the SFC 1097 Identifier carried in the packet header to a locally significant link 1098 identifier, e.g., VLAN-ID, and a method to construct and encapsulate 1099 the SFC header back to the packets when they come back from the 1100 attached SFs. 1102 This approach does not require using an end-to-end signaling protocol 1103 among Classier nodes and SFF nodes. However, there may be problems 1104 encountered if SFF nodes are not updated in the proper order or not 1105 at the same time. For example, if the SFF "A" and SFF "C" get flow 1106 steering policies at slightly different times, some packets might not 1107 be directed to some service functions on a chain. 1109 Authors' Addresses 1111 Hongyu Li 1112 Huawei 1113 Huawei Industrial Base,Bantian,Longgang 1114 Shenzhen 1115 China 1117 EMail: hongyu.li@huawei.com 1118 Qin Wu 1119 Huawei 1120 101 Software Avenue, Yuhua District 1121 Nanjing, Jiangsu 210012 1122 China 1124 EMail: bill.wu@huawei.com 1126 Yong(Oliver) Huang 1127 Huawei 1128 Huawei Industrial Base,Bantian,Longgang 1129 Shenzhen 1130 China 1132 EMail: oliver.huang@huawei.com 1134 Mohamed Boucadair (editor) 1135 France Telecom 1136 Rennes 35000 1137 France 1139 EMail: mohamed.boucadair@orange.com 1141 Christian Jacquenet 1142 France Telecom 1143 Rennes 35000 1144 France 1146 EMail: christian.jacquenet@orange.com 1148 Walter Haeffner 1149 Vodafone D2 GmbH 1150 Ferdinand-Braun-Platz 1 1151 Duesseldorf 40549 1152 DE 1154 EMail: walter.haeffner@vodafone.com 1155 Seungik Lee 1156 ETRI 1157 218 Gajeong-ro Yuseung-Gu 1158 Daejeon 305-700 1159 Korea 1161 Phone: +82 42 860 1483 1162 EMail: seungiklee@etri.re.kr 1164 Ron Parker 1165 Affirmed Networks 1166 Acton 1167 MA 01720 1168 USA 1170 EMail: ron_parker@affirmednetworks.com 1172 Linda Dunbar 1173 Huawei Technologies 1174 USA 1176 EMail: ldunbar@huawei.com 1178 Andrew Malis 1179 Huawei Technologies 1180 USA 1182 EMail: agmalis@gmail.com 1184 Joel M. Halpern 1185 Ericsson 1187 EMail: joel.halpern@ericsson.com 1189 Tirumaleswar Reddy 1190 Cisco Systems, Inc. 1191 Cessna Business Park, Varthur Hobli 1192 Sarjapur Marathalli Outer Ring Road 1193 Bangalore, Karnataka 560103 1194 India 1196 EMail: tireddy@cisco.com 1197 Prashanth Patil 1198 Cisco Systems, Inc. 1199 Bangalore 1200 India 1202 EMail: praspati@cisco.com