Internet Engineering Task Force S. Jiang
Internet-Draft Huawei Technologies Co., Ltd
Intended status: Informational R. Zhang
Expires: November 10, 2014 China Telecom
May 9, 2014
COllaborative NETwork (CONET) Gap Analysis
draft-jiang-intarea-conet-gap-analysis-00
Abstract
In order to efficiently distinguish ICPs' traffic, a new network
operation model - COllaborative NETwork is proposed. The traffic
recognization is based on traffic of ICPs' products actively carries
collaborative identifiers that both ISPs and ICPs reach consensus in
a coordination way. This document analyzes the tecnical gap between
the current network functions and required network capability to
support COllaborative NETwork.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 10, 2014.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Jiang & Zhang Expires November 10, 2014 [Page 1]
Internet-Draft Collaborative Network Gap Analysis May 2014
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Overview of Technical Consideratins . . . . . . . . . . . . . 3
3. Traffic Identifiers . . . . . . . . . . . . . . . . . . . . . 3
4. Collaboration between ICPs and ISPs . . . . . . . . . . . . . 5
5. Identifying Traffics between End Users and Network . . . . . 7
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
9. Change log [RFC Editor: Please remove] . . . . . . . . . . . 8
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
10.1. Normative References . . . . . . . . . . . . . . . . . . 8
10.2. Informative References . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
While the Internet traffic is continually growing, more and more
Internet Content Providers (ICPs) realize the essentiality and
advantages to cooperate with Internet Service Providers (ISPs). In
order to serve their users better, ICPs raise an emerging requirement
that the traffic of their products needs to be treated differently,
both in traffic handling process and traffic accounting process.
[I-D.fan-intarea-conet-ps-uc] has described such requirement and use
cases in details.
The biggest technical challenge that network operators have to face
is to distinguish the traffic in a finer granularity. Nowadays, DPI
(Deep Packet Inspection) or DFI (Deep Flow Inspection) devices have
been widely used in identifying application information of the
traffic flows. However, they are expensive for both operational cost
Jiang & Zhang Expires November 10, 2014 [Page 2]
Internet-Draft Collaborative Network Gap Analysis May 2014
and time consumption. They are not be able to interact with real-
time network operations. A better approach would be traffic of ICPs'
products carries traffic identifiers that the network entities of
ISPs can easily recognise. The traffic identifers must be consistent
in collaboration between ISPs and ICPs. This approach is called
COllaborative NETwork (CONET) in this document.
This document analyzes the technical gap between the current network
functions and required network capability to support CONET.
2. Overview of Technical Consideratins
Overall, there are three technical aspects that need to be considered
in CONET, listed below. This section gives analysis to each aspects.
o A traffic identifier.
o An ICP notify/negotiate traffic identifiers and the desired
processing way regarding to both traffic handling and traffic
accounting with an ISP. The policies of traffic processing need
to be propagated and network entities need to be configured
correspondently within an ISP network.
o An end user host or application notify/negotiate their traffic
identifiers to/with network.
Note: the application-level communication between ICP servers and
their client applications on end user hosts, including dynamically
deciding the traffic identifier that end user hosts may embed in
packets, is out of scope. This document focuses on the network and
transport layers only.
3. Traffic Identifiers
The precondition that a traffic flow can be differentiately handling
is that it can recognized by the network entities. In this document,
the character in data packet that is used to distinguish a traffic
flow or a type/category of traffic flow is called traffic identifier.
There are a few requirements for traffic identifiers:
o Traffic identifiers must be stable, at least for a lifetime of
flow.
o Traffic identifiers should be easy to be inspectd by network
entities.
o Traffic identifiers should accurately distinguish traffic flow or
a type/category of traffic flow.
Jiang & Zhang Expires November 10, 2014 [Page 3]
Internet-Draft Collaborative Network Gap Analysis May 2014
o Traffic identifiers must be trustable and protected against any
tampers occuring during transportation.
o Some traffic identifiers may be convergencable in order to reduce
the management complexity on stateful records/policies.
o Some traffic identifiers may dynamically decide in the run time.
Its decision may involve dynamic involve ISPs, ICPs and end user
devices.
o Some traffic identifiers may not be set by the traffic initiators.
A intermediate node, for example a CPE or an igress router, may
remark or set new traffic identifier based on its traffic
recognition.
o Some traffic identifiers may be meaningful cross administrative
boundaries.
[I-D.fan-intarea-conet-ps-uc] analyzes two current used traffic
identifiers: application-level characteristic information used by DPI
and IP addresses of ICP servers. Each of them has a few issues,
summaried as below:
o Application-level characteristic information used by DPI.
Accuracy of application identification cannot be guaranteed. The
ability highly depends on vendors. The computing resource
consumption is very high. Furthermore, the usage of TLS [RFC5246]
and HTTPS [RFC2818] is increasing the difficulties of DPI.
o IP addresses of ICP servers. More granular traffic handling
cannot be satisfied because a single server may hold multiple
services that need to be distinguished. Cache/CDN uses different
IP addresses, which may be also shared with other ICPs.
There are also other traffic identifiers or components that may
compose traffic identifiers:
o IP addresses of end user devices. They are nature identifers that
can distinguish the communication node. However, one end user
node would have many traffics. CONET requires to recognite only
these traffics associated with certain ICPs. So, only IP
addresses of end user devices are not suffient. Furthermore, many
end user devices may be assigned private IPv4 addresses. These
addresses are replaced by pulic IPv4 addresses after Network
Address Translator (NAT, [RFC3022]).
o Port numbers. They are useful to distinguish flows/services from
the same node. However, it cannot be used to identify network
Jiang & Zhang Expires November 10, 2014 [Page 4]
Internet-Draft Collaborative Network Gap Analysis May 2014
traffics independently. It must be used together with identifiers
that distinguish nodes.
o Flow labels [RFC6437]. It is only available in IPv6 traffic. It
is changed for every flow. Like port numbers, flow labels cannot
be used to identify network traffics independently. Normally, it
is used as triple-tuple with source and destination address.
Because it is encoded in the IPv6 fixed header, it is easier to
recognite than port numbers. However, another disadvantage of
flow label is that it is not protected, particularly, there is no
mechanism to validate its integrity.
o DiffServ Field (Differentiated Services Field, [RFC2474]). It was
defined to identify the differentiated services that network
should apply on the packets. It is the explicit result for
network entities to apply different handling policies accordingly.
However, the precondition DiffServ field can be used is that there
is strong trust relatioship between the nodes that set DiffServ
Field and network entities.
Each of the abovementioned traffic identifiers has there own suitable
scenarios and limitations. New traffic identifiers may be difined in
the future.
For many scenarios, the combination of abovementioned traffic
identifiers may be used. The 5-tuple (source IP address, destination
IP address, source port number, destination port number, IP protocol
number) is the most common used traffic identifier to identify a flow
accurately in IP layer. However, 5-tuple itself is not tighty
assicated with upper-layer applications or contents. There are
mapping gaps to use 5-tuple to identify traffics relevant to a
certain ICP or its certain services. Another issue of 5-tuple is it
is not convergencable. Managing numerous 5-tuple may be a big burden
for ISPs. Furthermore, the existing of NATs change the 5-tuple of
traffic in the way. Consequently, the traffic identifiers assoicated
with IPv4 addresses have to very complicated management issues.
4. Collaboration between ICPs and ISPs
Firstly, an ICP need to reach consistent with an ISP on traffic
identifiers, which network would recognite the ICP traffic
accordingly.
Then, the ICP notify the specific traffic identifiers, which may have
multiple categories, and the desired policies associated with each
traffic categories, to the ISP. Then the ISP network can apply these
policies when actual traffics happen.
Jiang & Zhang Expires November 10, 2014 [Page 5]
Internet-Draft Collaborative Network Gap Analysis May 2014
The notification process between ICPs and ISPs should be dynamical
through a protocol/interface. In 3GPP mobile network, Rx interface
[Rx-3GPP] has been defined to allow interaction between ICPs and ISPs
using Diameter [RFC6733], and AF-Application-identifier AVP has also
been defined to indicate the particular service that the AF
(Application Function) service session belongs to. This information
may be used by the PCRF (Policy and Charging Rule Function) to
differentiate QoS for different application services.
However, currently few ICPs have support Diameter protocol.
Considering ICP is more familiar with XML based protocol, 3GPP is
working on the solutions for an XML based protocol (e.g. SOAP,
Restful HTTP, etc.) over Rx interface between the AF and the PCRF
[XML_AF_PCRF].
With in an ISP network, Traffic management policy must be propagated
to network entities that actually handle traffics. In 3GPP mobile
network, Gx interface [Gx-3GPP] has been defined to enable PCRF
autonomically configures matching rules regarding to a certain
traffic on GGSN/P-GW.
BroadBand Forum has also defined the Broadband Policy Control
Framework [BPCF] that meets the similar function of Rx and Gx
interfaces in the fixed broadband networks.
This model has two limitations as below:
1. Some ICPs may have one server address, but with different sub-
content behind that server address. Because current PCRF only
focus on 5-tuple traffic description, it may be difficult to
support fine-grained traffic identification.
2. Because of lacking involvement from end user devices/
applications, user clients will be difficult to be identified if
they are behind NAT (they have NATed IPv4 addresses). Even by
correlating the authentication process which could send user
information to PCRF, it will still make the whole process very
complicated.
Another major issue is that this model is ISP-orientied. ICP
traffics commonly cross multiple ISP networks. Hence, an ICP may
have to work with multiple ISPs independently. The traffic handling
across different administration domain may be different, giving the
possibility that different ISPs may use different traffic identifiers
and different policies. When there was a traffic issue, such as high
latency or packet lost, it may be a challenge for the ICP to find out
which network has problem.
Jiang & Zhang Expires November 10, 2014 [Page 6]
Internet-Draft Collaborative Network Gap Analysis May 2014
5. Identifying Traffics between End Users and Network
Recognition of the traffic from ICP servers to end users may not be
very difficult giving the natural convergency. However, when an end
user host or application initiates traffic towards ICP contents,
particularly some contents may be obtained cache/CDN deployed in the
network, it is needed for the end user host or application actively
notifiying its traffic to the network.
The traffic identifiers used by end user host or application:
o may be authorised and assigned by the ICPs after application-level
authentication or out-of-band authentication. Then, these traffic
identifiers would be carried by packets.
o may be dynamically decided by the negotiation between the end user
host or application and the network. Out-of-band controlling
policies, including network authentication and authorization, may
also be notified/negotiated together.
o may just describe the traffic characters, and leave the network to
recognite them, then mapped into other traffic identifiers that
meaningful and explicit within the network.
There are many exisiting protocols that may be extended to realize
the out-of-band controlling mechanism. However, these exisiting
protocols was designed to serve their own purposes and scenarios.
Defining a new dedicated protocol may also be an opinion.
o Resource ReSerVation Protocol (RSVP, [RFC2205]) is a resource
reservation setup protocol. However, so far, that is mainly used
among network entities. Next Steps in Signaling (NSIS, [RFC4080])
provides duplicated function as RSVP. It is not widely deployed.
o Dynamic Host Configuration Protocol ([RFC2131], [RFC3315]) was
designed to provide information, including assigning host IP
address, from network to hosts. It is a one-way information
provisioning protocol. It does not provide authentication and
information protection function.
o Radius [RFC2865] and Diameter [RFC6733] provides an
Authentication, Authorization and Accounting for network access.
Currently, there is no many in-band mechanisms, in which traffic
identifier that the end user devices/applications set up is carried
within packets. In-band mechanisms is able to traverse
administration domains, and it is possible the traffic gets identical
handling. The precondition of in-band mechanisms is that the
Jiang & Zhang Expires November 10, 2014 [Page 7]
Internet-Draft Collaborative Network Gap Analysis May 2014
integrity of traffic identifiers can be validated by network
entities.
6. Security Considerations
A trust relationship should be established among end users, ICPs and
ISPs. The authentication and authorization for end user access
should be as easy as possible. OAUTH protocol [RFC6749] & OpenID
[OpenID] may be adopted.
Traffic identifiers with packets should be protocted against any
tampers occuring during transportation.
The protocol that used to notify/negotiate their traffic identifiers
to/with network should be protected.
7. IANA Considerations
This document includes no request to IANA.
8. Acknowledgements
Valuable comments were received from Peng Fan, Farooq Bari, Weihua
Qiao and Hui Deng.
This document was produced using the xml2rfc tool [RFC2629].
9. Change log [RFC Editor: Please remove]
draft-jiang-intarea-conet-gap-analysis-00: original version,
2014-05-09.
10. References
10.1. Normative References
[RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC
2131, March 1997.
[RFC2205] Braden, B., Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
Functional Specification", RFC 2205, September 1997.
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black,
"Definition of the Differentiated Services Field (DS
Field) in the IPv4 and IPv6 Headers", RFC 2474, December
1998.
Jiang & Zhang Expires November 10, 2014 [Page 8]
Internet-Draft Collaborative Network Gap Analysis May 2014
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)", RFC
2865, June 2000.
[RFC3022] Srisuresh, P. and K. Egevang, "Traditional IP Network
Address Translator (Traditional NAT)", RFC 3022, January
2001.
[RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
and M. Carney, "Dynamic Host Configuration Protocol for
IPv6 (DHCPv6)", RFC 3315, July 2003.
[RFC4080] Hancock, R., Karagiannis, G., Loughney, J., and S. Van den
Bosch, "Next Steps in Signaling (NSIS): Framework", RFC
4080, June 2005.
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security
(TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC6437] Amante, S., Carpenter, B., Jiang, S., and J. Rajahalme,
"IPv6 Flow Label Specification", RFC 6437, November 2011.
[RFC6733] Fajardo, V., Arkko, J., Loughney, J., and G. Zorn,
"Diameter Base Protocol", RFC 6733, October 2012.
[RFC6749] Hardt, D., "The OAuth 2.0 Authorization Framework", RFC
6749, October 2012.
10.2. Informative References
[BPCF] BroadBand Forum Technical Report 134, "Broadband Policy
Control Framework", July 2012.
[Gx-3GPP] 3GPP Work Item 13029, "Gx reference point for Policy and
Charging Control", July 2008.
[I-D.fan-intarea-conet-ps-uc]
Fan, P. and H. Deng, "CONET (Collaborative Network)
Problem Statement and Use Cases", draft-fan-intarea-conet-
ps-uc-00 (work in progress), March 2014.
[OpenID] OpenID Foundation, "OpenID Authentication 2.0 - Final",
December 2007, <http://specs.openid.net/auth/2.0>.
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
Jiang & Zhang Expires November 10, 2014 [Page 9]
Internet-Draft Collaborative Network Gap Analysis May 2014
[Rx-3GPP] 3GPP Technical Specification 29.214, "Policy and charging
control over Rx reference point", July 2008.
[XML_AF_PCRF]
3GPP Technical Report 29.817, "Study on eXtensible Markup
Language (XML) based access of the Application Function
(AF) to the Policy and Charging Rules Function (PCRF)",
March 2014.
Authors' Addresses
Sheng Jiang
Huawei Technologies Co., Ltd
Q14, Huawei Campus, No.156 Beiqing Road
Hai-Dian District, Beijing, 100095
P.R. China
Email: jiangsheng@huawei.com
Rong Zhang
China Telecom
No.109 Zhongshandadao avenue
Guangzhou 510630
China
Email: zhangr@gsta.com
Jiang & Zhang Expires November 10, 2014 [Page 10]