idnits 2.17.1 draft-conet-aeon-gap-analysis-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 : ---------------------------------------------------------------------------- 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 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 (October 24, 2014) is 3465 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** Obsolete normative reference: RFC 5246 (Obsoleted by RFC 8446) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) ** Obsolete normative reference: RFC 5766 (Obsoleted by RFC 8656) == Outdated reference: A later version (-18) exists of draft-ietf-netconf-restconf-02 == Outdated reference: A later version (-16) exists of draft-ietf-rtcweb-use-cases-and-requirements-14 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 5 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Jiang 3 Internet-Draft Huawei Technologies Co., Ltd 4 Intended status: Informational H. Deng 5 Expires: April 27, 2015 China Mobile 6 F. Bari 7 AT&T 8 R. Zhang 9 China Telecom 10 S. Krishnan 11 Ericsson 12 Y. Fu 13 Huawei Technologies Co., Ltd 14 October 24, 2014 16 Application Enabled COllaborative NETworking Gap Analysis 17 draft-conet-aeon-gap-analysis-01 19 Abstract 21 Identification and treatment of application flows have become more 22 and more important for network operators. In order to efficiently 23 distinguish ICPs' traffic, coordination between ISPs and ICPs is 24 required. IP flow identification can be based on ICPs' traffic 25 carrying some mutually agreed identifiers. This document analyzes 26 the technical gap between the current network functions and required 27 network capability to enable such functionality. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on April 27, 2015. 46 Copyright Notice 48 Copyright (c) 2014 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 76 2. Overview of Technical Considerations . . . . . . . . . . . . 3 77 3. Traffic Identifiers . . . . . . . . . . . . . . . . . . . . . 4 78 4. Collaboration between ICPs and ISPs . . . . . . . . . . . . . 7 79 5. Identifying Traffics between End Users and Network . . . . . 8 80 6. Limitations of Existing Signaling Mechanisms . . . . . . . . 9 81 7. Efforts in Progress . . . . . . . . . . . . . . . . . . . . . 10 82 8. Security Considerations . . . . . . . . . . . . . . . . . . . 12 83 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 84 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 12 85 11. Change log [RFC Editor: Please remove] . . . . . . . . . . . 12 86 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 87 12.1. Normative References . . . . . . . . . . . . . . . . . . 12 88 12.2. Informative References . . . . . . . . . . . . . . . . . 14 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15 91 1. Introduction 93 While the Internet traffic is continually growing, more and more ICPs 94 (Internet Content Providers) realize the essentiality and advantages 95 of cooperating with ISPs (Internet Service Providers). In order to 96 serve their users better, ICPs have an emerging requirement that the 97 traffic of their products needs to be treated differently, both in 98 traffic handling process as well as in traffic accounting process. 99 [I-D.conet-aeon-problem-statement] has described such problems and 100 related requirements. 102 The biggest technical challenge that network operators or the ISPs 103 face is of distinguishing the traffic in finer granularity. 104 Nowadays, DPI (Deep Packet Inspection) or DFI (Deep Flow Inspection) 105 mechanisms have been widely used in identifying application 106 information specific to individual IP flows. However, they are 107 expensive both operationally and computationally. In many cases, 108 they are also not able to interact with real-time network operations. 109 An alternative approach would be that the traffic from ICPs carries 110 traffic identifiers that the network entities of ISPs can recognize 111 and act on. For that to properly work, the traffic identifiers must 112 be mutually understood by ISPs and ICPs. 114 This document analyzes the technical gap between the current network 115 functions and required network capability. 117 2. Overview of Technical Considerations 119 Overall, there are four technical aspects that need to be considered, 120 as listed below. 122 o A traffic identifier. 124 o An ICP notify/negotiate traffic identifiers and the desired 125 processing way regarding both traffic handling and traffic 126 accounting with an ISP. The policies of traffic processing need 127 to be propagated and corresponding network entities need to be 128 configured within an ISP network. 130 o Signaling/negotiation of traffic identifier by an end user host or 131 application to/with network. 133 o The information authentication and integrity protection mechanism. 135 Note: the application-level communication between ICP servers and 136 their client applications on end user hosts, including dynamically 137 deciding the traffic identifier that end user hosts may embed in 138 packets, is out of scope. This document focuses on only the network 139 layer and transport layer. 141 3. Traffic Identifiers 143 The precondition for a traffic flow to be handled differently is that 144 it can be recognized by the network entities. In this document, the 145 field in data packet that is used to distinguish a traffic flow or a 146 type/category of traffic flow is called traffic identifier. There 147 are a few requirements for traffic identifiers: 149 o Traffic identifiers must be stable, at least for the lifetime of 150 an IP flow. 152 o Traffic identifiers should be easy to inspect by the network 153 entities. 155 o Traffic identifiers should accurately distinguish IP traffic flow 156 or a type/category of traffic flow. 158 o Traffic identifiers must be trustable and protected against 159 tampering during transportation. 161 o Some traffic identifiers may be aggregated in order to reduce the 162 management complexity on stateful records/policies. 164 o Some traffic identifiers may be dynamically decided just before 165 the real traffic is generated. The decision of identifiers may 166 dynamically involve ISPs, ICPs and end user devices. 168 o Some traffic identifiers may not be set by the traffic initiators. 169 A intermediate node, for example a CPE or an ingress router, may 170 re-mark or set new traffic identifier based on its traffic 171 recognition. 173 o Some traffic identifiers may be meaningful across network 174 administrative boundaries. 176 Current common approach to identify traffic flows of applications in 177 a network is to rely on dedicated content aware devices. These 178 devices not only parse fields on the IP and transport layers but also 179 recognize application related information above transport layer. 180 Content awareness ability mainly utilizes DPI function, which 181 inspects characteristic signature (e.g. key string, binary sequence, 182 etc.), and DFI function, which analyzes statistical characteristic 183 and connection behavior of traffic flows, to identify application. 184 However, there are limitations in deployment and operation of the 185 ability. 187 o Since both DPI and DFI are essentially deductive methods difficult 188 to fully grasp the characteristics of applications, accuracy of 189 application identification cannot be guaranteed. Error or 190 omission is inevitable. 192 o Internet applications are expected to change frequently, and so 193 are their characteristics. There will be a time lag between a 194 complete application traffic analysis and update of signature 195 database when a new application or a new version appears, and this 196 also contributes to the inaccuracy of identification. 198 o Content identification mechanisms are usually proprietary and act 199 as a black box. There is no standard way in their implementation 200 or a way of benchmarking. So the ability highly depends on 201 vendors. Different boxes are likely to give different 202 identification results to the same traffic. 204 o Content identification functionality requires parsing the payload 205 of IP packets, leading to very high use of computational 206 resources. Built-in content identification function modules in 207 network elements will therefore affect the forwarding performance 208 and thus impact data transmission. 210 o Investment costs cannot be neglected. Sometimes the cost to 211 identify the traffic is no less than that of forwarding the 212 traffic. Operational cost of the additional nodes is also an 213 important issue. More potential failure points will also affect 214 network quality. 216 o Furthermore, the usage of TLS (Transport Layer Security, 217 [RFC5246]) and HTTPS [RFC2818] is increasing the difficulties of 218 DPI. 220 Another simpler approach is to identify traffic by IP addresses. An 221 example would be a white list of IP addresses of an application of 222 the ICP, and network can match traffic with the list to pick the 223 application. This approach will have limitations when dealing with 224 more complex scenarios. 226 o More granular traffic handling cannot be satisfied. If part of 227 the application traffic or traffic of some of the users is to be 228 treated separately, IP based identification is too coarse. For 229 example, the real-time game traffic and video traffic for the same 230 website are likely to receive different treatment but target to 231 the same IP address; traffics from two users to the same server 232 may also need to be distinguished. 234 o If cache or CDN (Content Distribution Network) is deployed in the 235 network, then different users are likely to visit different 236 addresses, and the addresses are likely to be different from the 237 original addresses of ICPs. Managing the list will have to 238 consider the IP addresses of caches and CDN nodes deployed. 240 o Configuring the IP address list is not always extensible as the 241 addresses may change, and sometimes it is not supposed to expose 242 the addresses of ICPs. 244 There are also other traffic identifiers or components that may get 245 used as traffic identifiers: 247 o IP addresses of end user devices. They are natural identifiers 248 that can distinguish the communication nodes. However, one end 249 user node would have many IP traffic flows. There is requirement 250 to recognize only the traffics associated with certain ICPs. So, 251 only IP addresses of end user devices are not sufficient. 252 Furthermore, many end user devices may be assigned private IPv4 253 addresses. These addresses are replaced by public IPv4 addresses 254 after NAT (Network Address Translator, [RFC3022]). 256 o Port numbers. They are useful to distinguish flows/services from 257 the same node. However, it cannot be used to identify network 258 traffic independently. It must be used together with identifiers 259 that distinguish nodes. 261 o Flow labels [RFC6437]. It is only available in IPv6 traffic. It 262 is changed for every flow. Like port numbers, flow labels cannot 263 be used to identify network traffics independently. Normally, it 264 is used as triple-tuple with source and destination address. 265 Because it is encoded in the IPv6 fixed header, it is easier to 266 recognize than port numbers. However, another disadvantage of 267 flow label is that it is not protected, particularly, there is no 268 mechanism to validate its integrity. 270 o DiffServ Field (Differentiated Services Field, [RFC2474]). It was 271 defined to identify the differentiated services that network 272 should apply on the packets. It is the explicit result for 273 network entities to apply different handling policies accordingly. 274 However, the precondition DiffServ field can be used is that there 275 is strong trust relationship between the nodes that set DiffServ 276 Field and network entities. 278 Each of the above mentioned traffic identifiers have their own 279 suitable use cases and possible limitations. 281 For many scenarios, the combination of abovementioned traffic 282 identifiers may be used. The 5-tuple (source IP address, destination 283 IP address, source port number, destination port number, IP protocol 284 number) is the most commonly used traffic identifier to identify a 285 flow accurately in IP layer. However, 5-tuple itself is not tightly 286 associated with upper-layer applications or contents. There are 287 mapping gaps to use 5-tuple to identify traffics relevant to a 288 certain ICP or its certain services. Another issue of 5-tuple is 289 that 5-tuple cannot be easily aggregated. Managing numerous 5-tuple 290 may be a big burden for ISPs. Furthermore, the existence of NATs 291 makes the use of the 5-tuple difficult. Consequently, the traffic 292 identifiers associated with IPv4 addresses become a very complicated 293 management issue. 295 4. Collaboration between ICPs and ISPs 297 Firstly, ICP needs to define traffic identifiers in consultation with 298 ISP. 300 The ICP defines the specific traffic identifiers, which may have 301 multiple categories, and the desired policies associated with each 302 traffic category, in consultation with the ISP. Then the ISP network 303 can apply these policies to actual network traffic. 305 The notification process between ICPs and ISPs can be dynamic through 306 a protocol/interface. In 3GPP (3rd Generation Partnership Project) 307 mobile network, Rx interface [Rx-3GPP] has been defined to allow 308 interaction between ICPs and ISPs using Diameter [RFC6733], and AF- 309 Application-identifier AVP has also been defined to indicate the 310 particular service that the AF (Application Function) service session 311 belongs to. This information may be used by the PCRF (Policy and 312 Charging Rule Function) to differentiate QoS for different 313 application services. 315 However, currently few ICPs have support for Diameter protocol. 316 Considering ICP is more familiar with XML based protocol, 3GPP is 317 working on the solutions for an XML based protocol (e.g. SOAP, 318 Restful HTTP, etc.) over Rx interface between the AF and the PCRF 319 [XML_AF_PCRF]. 321 Within an ISP network, traffic management policy must be propagated 322 to network entities that actually handle traffics. In 3GPP mobile 323 network, Gx interface [Gx-3GPP] has been defined to enable PCRF 324 autonomically configures matching rules regarding to a certain 325 traffic on GGSN/P-GW. 327 The BroadBand Forum has also defined the Broadband Policy Control 328 Framework [BPCF] that meets the similar function of Rx and Gx 329 interfaces in the fixed broadband networks. 331 This model has two limitations as below: 333 1. Some ICPs may have one server address, but with different sub- 334 content behind that server address. Because current PCRF only 335 focus on 5-tuple traffic description, it may be difficult to 336 support fine-grained traffic identification. 338 2. Because of lack of involvement from end user devices/ 339 applications, it will be difficult and more complex to identify 340 devices if they are behind NAT (they have NATed IPv4 addresses). 342 Another major issue is that this model is ISP-oriented. ICP traffics 343 commonly cross multiple ISP networks. Hence, an ICP may have to work 344 with multiple ISPs independently. The traffic handling across 345 different administration domain may be different, giving the 346 possibility that different ISPs may use different traffic identifiers 347 and different policies. When there was a traffic issue, such as high 348 latency or packet lost, it may be a challenge for the ICP to find out 349 which network has problem. 351 5. Identifying Traffics between End Users and Network 353 When an end user host or application initiates traffic towards ICP 354 contents, it is possible that the content instead is retrieved from a 355 cache/CDN that is deployed in the operator network. In that case, 356 the traffic identifier provided from the end user host or application 357 to the network is used to classify traffic. 359 The traffic identifiers used by end user host or application: 361 o may be authorized and assigned by the ICPs after application-level 362 authentication or out-of-band authentication. Then, these traffic 363 identifiers would be carried by packets. 365 o may be dynamically decided by the negotiation between the end user 366 host or application and the network. Out-of-band controlling 367 policies, including network authentication and authorization, may 368 also be notified/negotiated together. 370 o may just describe the traffic characteristics, and leave the 371 network to recognize them, then mapped into other traffic 372 identifiers that have explicit meaning within the network. 374 Currently, there are not many in-band mechanisms, where traffic 375 identifiers that the end user devices/applications set up are carried 376 within packets. In-band mechanisms allow packet traversal across 377 administration domains, with the traffic getting identical handling. 378 The precondition of in-band mechanisms is that the integrity of 379 traffic identifiers can be validated by network entities. 381 6. Limitations of Existing Signaling Mechanisms 383 The IETF has standardized several mechanisms involving explicit 384 signaling between applications and the network that may be used to 385 support visibility and differentiated network services workflows. 386 These existing protocols were designed to serve their own purposes 387 and scenarios. Unfortunately, none of these have experienced 388 widespread deployment success, nor are they well suited for the 389 usages described previously. Existing signaling options include the 390 following: 392 o RSVP (Resource Reservation Protocol, [RFC2205]), a resource 393 reservation setup protocol, is the original on-path signaling 394 protocol standardized by the IETF. It is transported out-of-band 395 and could be used to signal information about any transport 396 protocol traffic (it currently supports TCP and UDP). Its 397 original goal was to provide admission control. It is mainly used 398 among network entities. Its requirement for explicit reservation 399 of resources end to end proved too heavy for most network 400 environments. Its success was further impacted by its reliance on 401 router-alert, which often leads to RSVP packets being filtered by 402 intervening networks, and by its requirement for access to a raw 403 socket, something that is generally not available to applications 404 running in user space. To date, more lightweight signaling 405 workflows utilizing RSVP have not been standardized within the 406 IETF. 408 o NSIS (next Steps in Signaling, [RFC4080]) is the next iteration of 409 RSVP-like signaling defined by the IETF. It focused on the same 410 fundamental workflow as RSVP admission control as its main driver, 411 and because it did not provide significant enough use-case 412 benefits over RSVP, it has seen even less adoption than RSVP. 414 o DiffServ [RFC4594] and VAN Tagging [IEEE-802.1Q] style packet 415 marking can help provide QoS in some environments, but such 416 markings are often modified or removed at various points in the 417 network or when crossing network boundaries. There are additional 418 limitations when using DiffServ with real-time communications 419 applications, and the DART working group has been chartered to 420 write a document that explains the limitations that exist with 421 DiffServ when used with RTP in general as well in the specific 422 RTCWeb use cases [I-D.ietf-rtcweb-use-cases-and-requirements]. 424 o DHCP (Dynamic Host Configuration Protocol, [RFC2131], [RFC3315]) 425 was designed to provide information, including assigning host IP 426 address, from network to hosts. It is a one-way information 427 provisioning protocol. It does not provide authentication and 428 information protection function. 430 o Radius (Remote Authentication Dial In User Service, [RFC2865]) and 431 Diameter [RFC6733] provides an Authentication, Authorization and 432 Accounting for network access. 434 o ALTO (Application-Layer Traffic Optimization) [RFC7285] was 435 defined to help the application on the end user host or trackers 436 to select proper peer hosts. The ALTO server provides network 437 information (e.g. network topology information or cost, like AS 438 number) of candidates peer hosts that is capable of providing a 439 desired resource to the ALTO client where in AECON solution the 440 client provided the Qos information and traffic identifiers to the 441 server. The information in ALTO is transported by a request and 442 response processing based on HTTP protocol where in AECON solution 443 the information is notified by the client to the server . The ALTO 444 sever provides the Map Service, the Map-Filtering Service and the 445 Endpoint Cost (Ranking) Service to the ALTO client where the AECON 446 server provides the authentication and registration service to the 447 client. 449 7. Efforts in Progress 451 Not surprisingly, there are several evolving proposals that aim to 452 address the visibility and differentiated network services workflows 453 where existing approaches are not sufficient. Protocol specific 454 extensions are being defined, creating duplicate or inconsistent 455 information models. This results in operational complexity and a 456 need to convert information between protocols to leverage the best 457 protocol option for each specific use case. Examples of evolving 458 signaling options include the following: 460 o STUN (Session Traversal Utilities for NAT, [RFC5389]) is an on- 461 path, in-band signaling protocol that could be extended to provide 462 signaling to on-path network devices. It provides an easily 463 inspected packet signature, at least for transport protocols such 464 as UDP. Through its extensions TURN [RFC5766] and ICE [RFC5245], 465 it is becoming prevalent in application signaling driven by the 466 initial use-case of providing NAT and firewall traversal 467 capabilities and detecting local and remote candidates for peer- 468 to-peer media sessions. The TRAM working group is chartered to 469 update TURN and STUN to make them more suitable for WebRTC. 471 o PCP (Port Control Protocol, [RFC6887]) provides a mechanism to 472 describe a flow to the network. The primary driver for PCP is 473 creating port mappings on NAT and firewall devices. When doing 474 this, PCP pushes flow information from the host into the network 475 (specifically to the network's NAT or firewall device), and 476 receives information back from the network (from the NAT or 477 firewall device). It is not meant to be used end-to-end but 478 rather independently on one "edge" of a flow. 480 o RESTCONF [I-D.ietf-netconf-restconf] is a REST-like protocol that 481 provides a programmatic interface over HTTP for accessing data 482 defined in YANG, using the data stores defined in NETCONF 483 [RFC6241]. It is meant to provide a standard mechanism for web 484 applications to access the configuration data, operational data, 485 data-model specific protocol operations, and notification events 486 within a networking device, in a modular and extensible manner. 488 o I2RS (Interface to the Routing System) is a working group 489 chartered to provide interfaces for management applications, 490 network controllers, and user applications to make specific 491 demands on the network. 493 o ACTN (Abstraction and Control of Transport Networks) is a non- 494 working group mailing list intended to enable discussion of the 495 architecture, use-cases, and requirements that provide abstraction 496 and virtual control of transport networks to various applications/ 497 clients. 499 o Prefix coloring has been proposed for use in HOMENET and 6MAN 500 working groups to provide differentiated services to applications 501 based on IP address. 503 o RMCAT (RTP Media Congestion Avoidance Techniques) has been 504 chartered to address the lack of generally accepted congestion 505 control mechanisms for interactive real-time media, which is often 506 carried via sets of flows using RTP over UDP. Explicit exchanges 507 of flow characteristics and congestion information between 508 applications and the network could play an important role in such 509 mechanisms. 511 o TAPS (Transport Services) is an effort to create a working group 512 to define transport services that are exposed to internet 513 applications. A TAP enabled application identifies its needs of 514 the locally available transports services via an API. 516 Furthermore, the transport services of TAPS could benefit from 517 this communication with the network. 519 o SFC (Service Function Chaining) is a working group chartered to 520 address issues associated with the deployment of service functions 521 (e.g. firewalls, load balancers) in large-scale environments. 522 Service function chaining is the definition and instantiation of 523 an ordered set of instances of such service functions, and the 524 subsequent "steering" of traffic flows through those service 525 functions. 527 8. Security Considerations 529 A trust relationship should be established among end users, ICPs and 530 ISPs. The authentication and authorization for end user access 531 should be as easy as possible. OAUTH protocol [RFC6749] & OpenID 532 [OpenID] may be adopted. 534 Traffic identifiers with packets should be protected against any 535 tampering during transportation. 537 The protocol used to notify/negotiate the traffic identifiers to/with 538 network should be protected. 540 9. IANA Considerations 542 This document includes no request to IANA. 544 10. Acknowledgements 546 Valuable comments were received from Peng Fan, and Weihua Qiao. 548 This document was produced using the xml2rfc tool [RFC2629]. 550 11. Change log [RFC Editor: Please remove] 552 draft-conet-aeon-gap-analysis-00: original version, 2014-05-29. 554 draft-conet-aeon-gap-analysis-01: added gap analysis of the ALTO 555 mechanism, 2014-10-24. 557 12. References 559 12.1. Normative References 561 [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 562 2131, March 1997. 564 [RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S. 565 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 566 Functional Specification", RFC 2205, September 1997. 568 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 569 "Definition of the Differentiated Services Field (DS 570 Field) in the IPv4 and IPv6 Headers", RFC 2474, December 571 1998. 573 [RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson, 574 "Remote Authentication Dial In User Service (RADIUS)", RFC 575 2865, June 2000. 577 [RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network 578 Address Translator (Traditional NAT)", RFC 3022, January 579 2001. 581 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 582 and M. Carney, "Dynamic Host Configuration Protocol for 583 IPv6 (DHCPv6)", RFC 3315, July 2003. 585 [RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den 586 Bosch, "Next Steps in Signaling (NSIS): Framework", RFC 587 4080, June 2005. 589 [RFC4594] Babiarz, J., Chan, K., and F. Baker, "Configuration 590 Guidelines for DiffServ Service Classes", RFC 4594, August 591 2006. 593 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 594 (ICE): A Protocol for Network Address Translator (NAT) 595 Traversal for Offer/Answer Protocols", RFC 5245, April 596 2010. 598 [RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security 599 (TLS) Protocol Version 1.2", RFC 5246, August 2008. 601 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 602 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 603 October 2008. 605 [RFC5766] Mahy, R., Matthews, P., and J. Rosenberg, "Traversal Using 606 Relays around NAT (TURN): Relay Extensions to Session 607 Traversal Utilities for NAT (STUN)", RFC 5766, April 2010. 609 [RFC6241] Enns, R., Bjorklund, M., Schoenwaelder, J., and A. 610 Bierman, "Network Configuration Protocol (NETCONF)", RFC 611 6241, June 2011. 613 [RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme, 614 "IPv6 Flow Label Specification", RFC 6437, November 2011. 616 [RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn, 617 "Diameter Base Protocol", RFC 6733, October 2012. 619 [RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC 620 6749, October 2012. 622 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 623 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 624 2013. 626 [RFC7285] Alimi, R., Penno, R., Yang, Y., Kiesel, S., Previdi, S., 627 Roome, W., Shalunov, S., and R. Woundy, "Application-Layer 628 Traffic Optimization (ALTO) Protocol", RFC 7285, September 629 2014. 631 12.2. Informative References 633 [BPCF] BroadBand Forum Technical Report 134, "Broadband Policy 634 Control Framework", July 2012. 636 [Gx-3GPP] 3GPP Work Item 13029, "Gx reference point for Policy and 637 Charging Control", July 2008. 639 [I-D.conet-aeon-problem-statement] 640 Fan, P., Deng, H., Boucadair, M., Reddy, T., Eckel, C., 641 and B. Williams, "Application Enabled Collaborative 642 Networking: Problem Statement", draft-conet-aeon-problem- 643 statement-01 (work in progress), July 2014. 645 [I-D.ietf-netconf-restconf] 646 Bierman, A., Bjorklund, M., and K. Watsen, "RESTCONF 647 Protocol", draft-ietf-netconf-restconf-02 (work in 648 progress), October 2014. 650 [I-D.ietf-rtcweb-use-cases-and-requirements] 651 Holmberg, C., Hakansson, S., and G. Eriksson, "Web Real- 652 Time Communication Use-cases and Requirements", draft- 653 ietf-rtcweb-use-cases-and-requirements-14 (work in 654 progress), February 2014. 656 [IEEE-802.1Q] 657 IEEE 802.1Q, "IEEE Standards for Local and Metropolitan 658 Area Networks: Virtual Bridged Local Area Networks", 2005, 659 . 662 [OpenID] OpenID Foundation, "OpenID Authentication 2.0 - Final", 663 December 2007, . 665 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 666 June 1999. 668 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. 670 [Rx-3GPP] 3GPP Technical Specification 29.214, "Policy and charging 671 control over Rx reference point", July 2008. 673 [XML_AF_PCRF] 674 3GPP Technical Report 29.817, "Study on eXtensible Markup 675 Language (XML) based access of the Application Function 676 (AF) to the Policy and Charging Rules Function (PCRF)", 677 March 2014. 679 Authors' Addresses 681 Sheng Jiang 682 Huawei Technologies Co., Ltd 683 Q14, Huawei Campus, No.156 Beiqing Road 684 Hai-Dian District, Beijing, 100095 685 P.R. China 687 Email: jiangsheng@huawei.com 689 Hui Deng 690 China Mobile 691 Xuanwumenxi Ave. No.32 692 Beijing 100053 693 China 695 Email: denghui@chinamobile.com 697 Farooq Bari 698 AT&T 699 7277 164th Ave NE 700 Redmond WA 98052 701 USA 703 Email: farooq.bari@att.com 704 Rong Zhang 705 China Telecom 706 No.109 Zhongshandadao avenue 707 Guangzhou 510630 708 China 710 Email: zhangr@gsta.com 712 Suresh Krishnan 713 Ericsson 714 8400 Decarie Blvd. 715 Town of Mount Royal, QC 716 Canada 718 Phone: +1 514 345 7900 x42871 719 Email: suresh.krishnan@ericsson.com 721 Yu Fu 722 Huawei Technologies Co., Ltd 723 Q14, Huawei Campus, No.156 Beiqing Road 724 Hai-Dian District, Beijing, 100095 725 P.R. China 727 Email: eleven.fuyu@huawei.com