idnits 2.17.1 draft-penno-pcp-asdn-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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 8 instances of too long lines in the document, the longest one being 9 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 doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (September 29, 2013) is 3862 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC4594' is defined on line 482, but no explicit reference was found in the text == Outdated reference: A later version (-22) exists of draft-boucadair-connectivity-provisioning-protocol-00 == Outdated reference: A later version (-14) exists of draft-ietf-pcp-authentication-01 == Outdated reference: A later version (-09) exists of draft-sin-sdnrg-sdn-approach-03 Summary: 1 error (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Penno 3 Internet-Draft T. Reddy 4 Intended status: Standards Track Cisco Systems, Inc. 5 Expires: April 02, 2014 M. Boucadair 6 France Telecom 7 D. Wing 8 Cisco 9 S. Vinapamula 10 Juniper Networks, Inc. 11 September 29, 2013 13 Application Enabled SDN (A-SDN) 14 draft-penno-pcp-asdn-00 16 Abstract 18 To allow traversal of firewalls or provide additional network 19 services such as QoS or supplemental bandwidth, it is necessary to 20 deploy application-aware network elements. Such network elements are 21 costly to create, deploy, and are unable to adequately cope with 22 changes to the application itself, stifling innovation. 24 This document describes a different approach, where the application 25 explicitly signals its needs to the network. 27 Requirements Language 29 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 30 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 31 document are to be interpreted as described in RFC 2119 [RFC2119]. 33 Status of This Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 This Internet-Draft will expire on April 02, 2014. 50 Copyright Notice 52 Copyright (c) 2013 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the Simplified BSD License. 65 Table of Contents 67 1. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 2 68 2. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 69 3. Proposed Approach . . . . . . . . . . . . . . . . . . . . . . 4 70 4. Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 5. A-SDN Flows . . . . . . . . . . . . . . . . . . . . . . . . . 6 72 5.1. Signaling Prior to Flow Creation . . . . . . . . . . . . 7 73 5.2. Signaling After Flow Creation . . . . . . . . . . . . . . 8 74 5.3. Flow Removal Event . . . . . . . . . . . . . . . . . . . 8 75 5.4. Flow Modification . . . . . . . . . . . . . . . . . . . . 8 76 6. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 8 77 6.1. Flow Prioritization . . . . . . . . . . . . . . . . . . . 8 78 6.2. Flow High availability . . . . . . . . . . . . . . . . . 9 79 6.3. On-demand Bandwidth . . . . . . . . . . . . . . . . . . . 9 80 6.4. Analytics and Reporting . . . . . . . . . . . . . . . . . 9 81 7. Security Considerations . . . . . . . . . . . . . . . . . . . 9 82 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 83 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 9 84 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 10 85 10.1. Normative References . . . . . . . . . . . . . . . . . . 10 86 10.2. Informative References . . . . . . . . . . . . . . . . . 10 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 89 1. Problem Statement 91 In the context of ongoing efforts to add more automation and promote 92 means to dynamically interact with network resources (e.g., SDN- 93 labeled efforts) [I-D.sin-sdnrg-sdn-approach], various proposals are 94 made to accommodate the needs of Network Providers to program the 95 network with flow information and its associated metadata in order to 96 apply policies such as traffic prioritization. 98 Usually this programming is driven by a (centralized) controller that 99 gather flow-related information and associated metadata through an 100 army of probes, receiving a copy of the first packets of the flow, or 101 even having to be on-path for the first few packets of the flow but 102 not necessarily subsequent packets. But most of observed flows in 103 current usages are dynamic, time-bound (short lived for some of 104 them), possibly encrypted, peer-to-peer, possibly asymmetric, and 105 might have different priorities depending on network conditions, 106 direction, time of the day, and other factors. 108 This means that hairpinning of packets through a controller, deep 109 packet inspection, and other similar static methods such as portals 110 cannot be employed successfully to glean flow and metadata 111 information, and subsequently program the network. Therefore new 112 methods must be devised. 114 Unlike network-centric techniques, this document proposed an approach 115 which involved hosts and applications. 117 2. Scope 119 Considerations related to dynamic network provisioning negotiation 120 are out of scope. The reader can refer to 121 [I-D.boucadair-connectivity-provisioning-protocol] for more details. 123 The proposed architecture is not a replacement to existing legacy 124 techniques. It is an enhancement to existing network infrastructure 125 and service infrastructure than can be empowered by new features to 126 better accommodate application-specific needs while network and 127 services resources are also optimized and better partitioned. 129 This document does not propose to update all existing/future 130 applications to signal their network resources requirements; only a 131 subset of applications having specific connectivity requirements and 132 which require differentiated treatment at the network side are 133 expected to be updated to support the framework defined in this 134 document. 136 This document does not require an end-to-end signalling before actual 137 invocation of a service. 139 This document does not make any assumption on how differentiated 140 connectivity is delivered to end users. It is up to each 141 administrative entity managing a network to enforce its own 142 engineering policies, techniques and protocols. Note, differentiated 143 connectivity services can be provided by one or a combination of 144 several dimension (forwarding, routing, resources management). It is 145 out of scope of this document to elaborate on such aspects. 147 3. Proposed Approach 149 In order to offer more automation and dynamicity in resource usage 150 and invocation, this document proposes an architecture that is 151 composed of three parts: 153 1. Applications running on the end points (UEs, Server at a Data 154 Centers, CPE routers) must communicate or install flow and 155 associated metadata on network Elements. Means to discover such 156 Network Elements may be supported. 158 2. On the network side, a PDP (Policy Decision Point, [RFC2753]) is 159 responsible for orchestrating resources, generating policies and 160 trigger provisioning-related operations. 162 3. The PDP configures the on-path devices to accommodate the 163 signaled flow (e.g., open pinhole in the firewall, provide 164 prioritized network services for the flow). 166 The diagram below depicts the general architecture and message flow 167 for the Application-Enabled SDN (A-SDN). 169 Controller 171 +---------------+ 172 | PDP | 173 . __ . __ . __ . __ . __ . __ . | | 174 | | ________ | 175 . | |REST | | 176 | +----------->|Server | | 177 . Flow | 2 | '--------' | 178 | Install | +-----.---------+ 179 . Req | | 180 3| | 3 . Flow 181 . | | Install 182 | +------------|------+ . 183 . | Middlebox | | 184 ________ | | _________________ | ____v____ _________ 185 | | ____v___ || |I|REST || | Router | ... | Router | 186 | Client |..|Switch |....|| Server|W|Client || | Switch | | Switch | 187 +--------+ | | || |F| || '---------' '---------' 188 . '-------' |+-----------------+| 189 . +-------------------+ 190 . ^ 191 . . 192 . 1 . 193 .. . . . . . . . . . . . . . . 194 SDN signaling 195 Request (Flow + Metadata) 197 .... e.g., PCP 198 ---- e.g., REST 199 -.-. e.g., COPS-PR, Netconf, Openflow 201 A middlebox could be a CPE router, edge router, switch, wireless 202 access LAN controller, mobile gateway in 3GPP networks [RFC6459], or 203 any other flow-aware device. 205 This architecture provides several advantages such as: 207 o Host driven: The host (or application) is responsible for 208 requesting proper flows and associated metadata based on each 209 individual application needs. These needs may be time variant, 210 and driven by processes only understood by the applications (or 211 their users). The end host is the only entity in the system that 212 has all of the information required to make the correct service 213 request . This approach is compliant with requirements specific 214 to encrypted and multi-party flows. 216 o Network Authorization: If network access control is required, then 217 the host could also get authorization from the Application Server 218 trusted by the network in order to install flows and associated 219 actions (e.g., policies). The Application Server could be 220 deployed in a third party network. This is important for networks 221 which do not trust the host. 223 o Immediate incremental value for endpoints and applications: If, 224 for example, a CPE router that supports this architecture is 225 installed, applications could signal flow characteristics to the 226 network on both directions, traffic prioritization, firewall 227 pinholes and other services without changing the rest of the 228 network. Meaning, although steps 2 and 3 of the picture above 229 provide important end-to-end additional value they are not 230 necessary for end-to-edge. 232 o Access agnostic: An application should not care if it is on an 233 ADSL, Cable, Wi-Fi, 3G, Ethernet or other network type. 235 o Works across administrative domains: Home Network -> ISP1. Home 236 Network communicates with ISP1 using PCP. 238 o NAT and firewall aware: The flow information fed into the PDP will 239 have pre and post NAT information, allowing provisioning using 240 scoped IP addresses. 242 o Extensible: Client protocol can be extended to provide a wide 243 range of flow associated metadata. 245 o Multi-interface support: Based on network conditions clients can 246 switch from a Wi-Fi to a 3G interface, or install flows over 247 certain paths 249 4. Protocols 251 The first element of this architecture could be met by using the Port 252 Control Protocol (PCP) [RFC6887]. Indeed, PCP Flow Extension 253 [I-D.wing-pcp-flowdata] allows a PCP Client, usually a host, to 254 signal flow characteristics to the network, and the network to signal 255 its ability to accommodate that flow back to the host. 257 For example, a video streaming client knowing the address of the 258 remote server can request the required flow characteristics; for 259 example N-Mbps of upstream bandwidth, M-Mbps of downstream bandwidth, 260 low-latency, low-jitter etc. The network authorizes the request and 261 signals back to the host that it can (fully or partially) accommodate 262 the flow. 264 The second element of this architecture requires a protocol that has 265 built-in primitives for reliable near-real-time messages and, 266 ideally, sharing of information about network availability between 267 the network device and PDP. This element can be met by using REST, 268 Extensible Messaging and Presence Protocol (XMPP) [RFC6120] or 269 similar protocol. 271 Finally, the PDP should be able to install flows in routers or 272 switches and assign them a series of actions, modify flow actions, 273 collect statistics, or (more importantly) extend the provisioning of 274 these flows end-to-end. This third element of the architecture can 275 be met by using any of several flow provisioning protocols as part of 276 the PDP: 278 o PCP with the THIRD_PARTY option 280 o Netconf [RFC6241], COPS-PR [RFC3084] , or any similar protocol. 281 This document does not make any assumption on that interface. 283 5. A-SDN Flows 285 +---------------+ 286 | PDP | 287 . __ . __ . __ . __ . __ . __ . | | 288 | | ________ | 289 . | |REST | | 290 | +----------->|Server | | 291 . Flow | 2 | '--------' | 292 | Install | +-----.---------+ 293 . Req | | 294 3| | 3 . Flow 295 . | | Install 296 | +------------|------+ . 297 . | Middlebox | | 298 ________ | | _________________ | ____v____ _________ 299 | PCP | ____v___ || PCP |I|REST || | Router | ... | Router | 300 | Client |..|Switch |....|| Server|W|Client || | Switch | | Switch | 301 +--------+ | | || |F| || '---------' '---------' 302 . '-------' |+-----------------+| 303 . +-------------------+ 304 . ^ 305 . . 306 . 1 . 307 .. . . . . . . . . . . . . . . 308 PCP PEER 309 Req 311 .... PCP Message 312 ---- REST Messages 313 -.-. Netconf, COPS, etc. 315 5.1. Signaling Prior to Flow Creation 317 When an end host installs a flow in the middlebox through a PCP 318 message a REST API call is made to the PDP. This message will carry 319 the following information: 321 o Match condition: e.g., source/destination IP, source/destination 322 port, L4 Protocol, Port, VLAN Id etc. 324 o Metadata: e.g., metadata conveyed in PCP FLOWDATA option. 326 o Lifetime: e.g., lifetime in PCP response will be mapped to 327 idle_timeout and hard_timeout will be set to zero for the flow 328 entry. (idle_timeout and hard_timeout are defined in OpenFlow 329 switching protocol). This way PCP client is aware when the flow 330 entry will be removed. 332 The PDP uses an appropriate protocol (e.g., netconf, COPS-PR, 333 Openflow, etc.) to add/delete and modify flows and its metadata. For 334 example Openflow controller using Openflow protocol version 1.3 335 [OpenFlow] would get the information of configured queues and 336 associated property of each queue. The Openflow controller will 337 either associate the flow with relevant queue or instruct the 338 openflow-enabled network device to rewrite the DifServ CodePoint bits 339 for the flow based on the metadata in REST message. 341 5.2. Signaling After Flow Creation 343 The application can create a implicit flow normally as with a TCP 344 connection and later decide that it needs to modify it, for example, 345 extending its lifetime or associating metadata such as bandwidth, 346 delay, jitter, loss. 348 The mechanism is very similar to flow creation but does not require a 349 pre-signaling step. 351 5.3. Flow Removal Event 353 When a application-driven flow times out or is explicitly deleted, a 354 REST API call is generated in the case the controller wants to be 355 notified. This allows the PDP to delete the flow from other devices 356 in the network. 358 The PDP could also decide on its own to remove the installed flow. 359 In this case a PCP unsolicited response will be sent to the PCP 360 Client owner of such flow. 362 5.4. Flow Modification 364 After the PDP is notified of a flow creation, it can decide to modify 365 its metadata. In order to do that the controller will send modify 366 flow message through the appropriate protocol. 368 If the PDP succeeds in modifying a flow, a PCP unsolicited response 369 will be sent to the PCP Client owner of such flow. 371 6. Use Cases 373 This section describes some use-cases in which A-SDNs can be 374 beneficial. 376 6.1. Flow Prioritization 378 A video streaming client that wants to have a low loss, medium delay 379 service signals these flow characteristics in PCP FLOWDATA option. 380 PCP server would convey this metadata to a PDP which would in turn 381 add flow entry with inbound DSCP AF32 on SDN-enabled network devices. 383 Packets matching this flow will be marked AF32 and internally put in 384 an appropriate queue. More importantly, video packets should be 385 marked as close as possible to the source. 387 6.2. Flow High availability 389 One of the ways for the PCP Server to determine that the flows are 390 for business critical application is by using third party 391 authorization. A PCP server for such flows will checkpoint all the 392 state associated for such flows on the corresponding backup of active 393 for high availability. At a high level, this authorization works by 394 the PCP client first obtaining a cryptographic token from the 395 authorizing network element (e.g., call controller) and includes that 396 token in the PCP request. The PCP server in the network validates 397 the token and grants access. 399 6.3. On-demand Bandwidth 401 In managed or unmanaged services deployments an enterprise many times 402 needs more bandwidth for the entire link (all flows) or just some 403 specific applications. Moreover, it does not need those permanently 404 but just for a certain period of time. In this case the branch 405 router can dynamically request this service from the network, 406 streamlining service activation and modification. 408 6.4. Analytics and Reporting 410 Authorized applications within data centers and enterprises can 411 attach metadata such as media-type, application-id and group to the 412 flows which allows for ease and streamlined analytics and reporting 413 without deep packet inspection. 415 7. Security Considerations 417 Security considerations in [RFC6887] and PCP Authentication 418 [I-D.ietf-pcp-authentication] may need to be taken into account. For 419 REST mutual authentication is required and TLS could be used for 420 message integrity. Security-related consideration for the protocol 421 enabled between the PDP and underlying nodes are discussed in 422 [RFC6241] [RFC3084]. 424 8. IANA Considerations 426 This document does not require any action from IANA. 428 9. Acknowledgments 430 TODO. 432 10. References 434 10.1. Normative References 436 [I-D.wing-pcp-flowdata] 437 Wing, D., Penno, R., and T. Reddy, "PCP Flowdata Option", 438 draft-wing-pcp-flowdata-00 (work in progress), July 2013. 440 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 441 Requirement Levels", BCP 14, RFC 2119, March 1997. 443 [RFC6120] Saint-Andre, P., "Extensible Messaging and Presence 444 Protocol (XMPP): Core", RFC 6120, March 2011. 446 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 447 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 448 2013. 450 10.2. Informative References 452 [I-D.boucadair-connectivity-provisioning-protocol] 453 Boucadair, M. and C. Jacquenet, "Connectivity Provisioning 454 Negotiation Protocol (CPNP)", draft-boucadair- 455 connectivity-provisioning-protocol-00 (work in progress), 456 May 2013. 458 [I-D.ietf-pcp-authentication] 459 Wasserman, M., Hartman, S., and D. Zhang, "Port Control 460 Protocol (PCP) Authentication Mechanism", draft-ietf-pcp- 461 authentication-01 (work in progress), October 2012. 463 [I-D.sin-sdnrg-sdn-approach] 464 Boucadair, M. and C. Jacquenet, "Software-Defined 465 Networking: A Service Provider's Perspective", draft-sin- 466 sdnrg-sdn-approach-03 (work in progress), June 2013. 468 [OpenFlow] 469 OpenFlow, ., "OpenFlow Switch Specification", February 470 2011, . 473 [RFC2753] Yavatkar, R., Pendarakis, D., and R. Guerin, "A Framework 474 for Policy-based Admission Control", RFC 2753, January 475 2000. 477 [RFC3084] Chan, K., Seligson, J., Durham, D., Gai, S., McCloghrie, 478 K., Herzog, S., Reichmeyer, F., Yavatkar, R., and A. 479 Smith, "COPS Usage for Policy Provisioning (COPS-PR)", RFC 480 3084, March 2001. 482 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 483 Guidelines for DiffServ Service Classes", RFC 4594, August 484 2006. 486 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 487 Bierman, "Network Configuration Protocol (NETCONF)", RFC 488 6241, June 2011. 490 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 491 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 492 Partnership Project (3GPP) Evolved Packet System (EPS)", 493 RFC 6459, January 2012. 495 Authors' Addresses 497 Reinaldo Penno 498 Cisco Systems, Inc. 499 170 West Tasman Drive 500 San Jose 95134 501 USA 503 Email: repenno@cisco.com 505 Tirumaleswar Reddy 506 Cisco Systems, Inc. 507 Cessna Business Park, Varthur Hobli 508 Sarjapur Marathalli Outer Ring Road 509 Bangalore, Karnataka 560103 510 India 512 Email: tireddy@cisco.com 514 Mohamed Boucadair 515 France Telecom 516 Rennes 35000 517 France 519 Email: mohamed.boucadair@orange.com 520 Dan Wing 521 Cisco Systems, Inc. 522 170 West Tasman Drive 523 San Jose, California 95134 524 USA 526 Email: dwing@cisco.com 528 Suresh Vinapamula 529 Juniper Networks, Inc. 530 1194 N Mathilda Ave 531 Sunnyvale, California 94089 532 USA 534 Email: sureshk@juniper.net