Internet DRAFT - draft-sun-semantic-usecase
draft-sun-semantic-usecase
Network Working Group C. Xie
Internet-Draft Q. Sun
Intended status: Informational China Telecom
Expires: August 29, 2013 S. Jiang
Huawei Technologies Co., Ltd
February 25, 2013
Use case of IPv6 prefix semantics for operators
draft-sun-semantic-usecase-02
Abstract
Embedding certain semantics into IPv6 addresses will bring a lot of
benifits for operators to simplify network management and apply
operations accordingly[I-D.jiang-semantic-prefix]. This memo
illustrates the use case of semantic bits from operator's point of
view, and provides considerations on how to design the semantic bits
in IPv6 address.
Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119].
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 August 29, 2013.
Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved.
Xie, et al. Expires August 29, 2013 [Page 1]
Internet-Draft Semantic use case February 2013
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
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. How to design the semantic bits . . . . . . . . . . . . . . . 4
3. A use case for Semantic Prefix . . . . . . . . . . . . . . . . 6
3.1. Level-1 semantics . . . . . . . . . . . . . . . . . . . . 6
3.2. Level-2 semantics . . . . . . . . . . . . . . . . . . . . 7
4. Benifits of Semantic Use Case . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
Xie, et al. Expires August 29, 2013 [Page 2]
Internet-Draft Semantic use case February 2013
1. Introduction
[I-D.jiang-semantic-prefix] introduces embedded semantics prefix
solution in IPv6 context. With more and more differentiated
requirements raising in the current Internet, service operators may
want to apply more complicated policies for different kinds of
customers and services. Policy control servers are introduced
gradually in fixed network operator and mobile network operator.
However, all of these policies can only take action based on
efficient packet identification of different sematics.
The semantics are mainly used in a local region within an operator.
Carrying semantic bits directly in IPv6 prefix is not only efficient
for routers to do packet identification, but also suitable for
operators. It provides an easy access and trustable fundamental for
packet differentiated treatment.
For operators, several motivations to use semantic prefixes are as
follows:
1. Network Device management
In order to achieve easy management for network devices, operators
will usually apply a simple and specific numbering policy for network
devices. Besides, special-purpose security policies may be enforced
for network devices other than for customers and service platforms.
For example, when encountering a simple threat model from some
subscribers' address block, operators may only filter the specific
subscribers' address block other than the whole addresses network
devices and service platforms. As a result, separated and
specialized address space for network device will help to identify
the network device among numerous addresses and apply policy
accordingly.
2. Differentiated user management
In operator's network, different kinds of customers may have
different requirements for service provisioning. For example,
broadband access subscribers usually have lower priority than
enterprise customers. And even for broadband access subscribers,
different priorities can also be further divided to apply
differentiated policy, e.g. bandwidth limit, etc. In particular,
semantic prefix would be quite useful for identifying subscriber's
priority in downstream traffic across large-scale regions where
subscriber's profile is difficult to syncronize.
3. High-priority service guarantee
Xie, et al. Expires August 29, 2013 [Page 3]
Internet-Draft Semantic use case February 2013
Operators may provide their own ISP brokered services, .e.g. video
streaming, IPTV, VOIP, etc, which usually have higher priority
guarantee rent their IDC to third-party service platform, offering
high priority services, .e.g. video streaming, VOIP, etc.
4. Service-based Routing
Service-based routing usually has close relationship with operator's
network architecture. For example, some operators have distinct core
networks for different kinds of services. As a result, operators may
offer different routing policy for specific service platforms
.e.g.video streaming, VOIP, etc. Different routing policies may also
apply to high priority services. In this case, semantic embedded in
the IPv6 address will be very helpful to implement service-based
routing.
5. Security Control
For security requirement, operators need to take control and identify
of certain devices/customers in a quick manner.
6. Easy measurement and statistic
The semantic prefix provides explicit identifiers for measurement and
statistic. They are as simple as checking certain bits of address in
each packets.
The semantic bits should be defined after an operator have got its
IPv6 address pool. The embedded semantic bits should be carefully
designed. Firstly, the number of bits which can be used to carry
semantic information. Secondly, some sementics may easily raise the
implementation complexity on host and network devices. So careful
considerations and tradeoff should be taken in semantic design.
[I-D.jiang-semantic-prefix] has listed some semantics which may be
useful to network operators. In this document, we provide a use case
to use some selected semantics, achieving enhanced network management
and service provisioning ability with limited impact on existing
network infrustructure.
[Note: Further use cases could be added to reflect other requirements
and implementation possibility.]
2. How to design the semantic bits
Depending on the IPv6 address space that network operators received
from IANA or upstream network service providers, the number of
Xie, et al. Expires August 29, 2013 [Page 4]
Internet-Draft Semantic use case February 2013
arbitrary bits in prefix is different. For now, this document only
discusses unicast address within IP Version 6 Addressing Architecture
[RFC4291].
The following are some guidelines for operators to design the
semantic bits:
o Determine the number of semantic bits. Typically, ISPs with
millions subscribers would have /16 ~ /24 address space. It
allows 40~48 arbitrary bits in prefix to be set by network
operators (assuming the network is not strictly managed by
DHCPv6). However, many ISPs plan to assign /56 or even /48 for
subscribers, the arbitrary bits are reduced to 22~40.
Furthermore, within the arbitrary bits, the locator function of IP
address should be ensured first. Enough consideration should be
given for future expanding. Some address space may be wasted in
aggregation. For a Semantic Prefix Domain that organizes several
millions subscribers with a continuous IPv6 address block, 24 bits
for locator function is a minimum safe allocation. Hence, it is
recommended to use 4~12 bits in prefix for embedded semantics.
o The number of semantics should be limited. According to the above
analysis, the number of semantic bits left for operators is quite
limited. Therefore, network operator should only use necessary
semantics when they can bring benefits, especially IP-layer
policy, e.g. policy routing, access control and filtering, QoS,
network measurement, etc. Network operators should be very
careful to plan and manage the semantic field, and should self-
restrict NOT to put too many semantic into prefix. So that they
may avoid trap themselves into very complicated management issues.
o Semantic overlap should be largely avoided . Any potential
scenarios that a given address may be mapped two or more semantic
prefixes might be harmful. Otherwise, if one subscriber is
allocated with multiple semantics, context-based semantic
selection mechanism must been introduced which might increase the
complexity in device/hosts. In our use case, either the source
address or the destination address only belongs to one semantic so
as to simplify address selection process.
o The design of semantic bits should be scalable and stable from the
long-term. It should reflect the general potential network
strategy and policies in the future and should be defined in
highly abstracted way since there might be quite a lot of unknown
emerging services.
o Different size of addressing space should be planned carefully for
different semantics. Since different semantics usually consumes
Xie, et al. Expires August 29, 2013 [Page 5]
Internet-Draft Semantic use case February 2013
different size of address space, operators should plan the size of
address space according to the service model for different
semantics.
3. A use case for Semantic Prefix
As mentioned in section one, operators may have multiple requirements
to use semantics. These requirements are largely falling into two
categories: the first one is related to the network device features,
while the second one is related to services provision and subscriber
identification.
The functional usage of the semantics for the two categories are
quite different. For example, the semantics for the first category
does not need to carry QoS related information, but may need to
reflect network architecture of the operator; while the semantics in
the second category should reflect the QoS requirements of the given
subscriber/service.
With this in mind, in our use case, the semantics are defined
hierarchically, in which the first level is to define the function
types of the prefixes, and the second level is to define the further
usage within that specific prefix type.
3.1. Level-1 semantics
Level-1 semantics can be used to define the function types of the
prefixes.
Function type (FT): the value of this field is to indicate the
functional usage of this prefix. The typical types for operators
include network device, subscriber and service.
The following is the example of FT value.
Xie, et al. Expires August 29, 2013 [Page 6]
Internet-Draft Semantic use case February 2013
IPv6 Prefix
+--------+--------+------------------------------------------------+
| | FT | |
+--------+--------+------------------------------------------------+
/ \
/ \
+--------------+-------+
|000: network device |
|001: service platform|
|010: service platform|
|011: subscriber |
|100: subscriber |
|101: subscriber |
|110: reserved |
+----------------------+
Figure 1: FT Value Example
In this example, one prefix type may have multiple FT values. For
example, FT value of the subscriber prefix can be
010,011,100,101,110,111, The portion of each type should be estimated
according to the actual requirements for operators.
With the above FT defintion, the whole IPv6 addressing space is
firstly divided into three parts(as in the following figure).
+----------------------------------------------------------------+
| IPv6 Addressing Space |
+------------------------+--------------------+------------------+
| Subscriber | Service Platform | Network Device |
| Addressing | Addressing | Addressing |
| Space | Space | Space |
+--------+--------+----------------------------------------------+
Figure 2: Addressing Space Division
3.2. Level-2 semantics
Level-2 semantics is to define more detailed usage in different
Function Types (addressing space).
1. Network Device Type (NDT)
Network Device Type (NDT) is to indicate different types of network
devices. Normally, one operator may have multiple networks,
e.g.backbone network, mobile network, ISP brokered service network,
etc. Using NDT field to indicate specific network within an operator
may help to apply some routing policies. Besied, implementing the
Xie, et al. Expires August 29, 2013 [Page 7]
Internet-Draft Semantic use case February 2013
NDT field in the left-most bits means that a single, simple access-
control list implemented across all networking devices would be
enough to enforce effective traffic segregation. The Locator field
is put behind NDT to indicate the region of a certain device.
One example is shown in the following figure:
IPv6 Prefix
+--------+--------+------+-----------------------------------------+
| | FT(000)| NDT | Locator | Network Device bits |
+--------+--------+------+-----------------------------------------+
/ \
/ \
+------------+----+
|000: Network 1 |
|001: Network 1 |
|010: Network 2 |
|011: Network 2 |
|100: Network 2 |
|101: Network 2 |
|110: Network 2 |
+-----------------+
Figure 3: NDT Value Example
2. Subscriber type (ST)
Subscriber type is to indicate different types of subscribers, e.g.
wireline broadband subscriber, mobile subscriber, enterprise, WiFi,
etc. This type of prefix is allocated to end users. In particular,
further divisions can be taken on subscriber's priorities within one
type, e.g. golden broadband subscriber, silver broadband subscriber
and bronze broadband subscriber. This definition is based on
operator's local service model.
Here, the Locator will reflect the different regions of a subscriber,
and is put before ST for better routing aggregation.
One example is shown in the following figure:
Xie, et al. Expires August 29, 2013 [Page 8]
Internet-Draft Semantic use case February 2013
IPv6 Prefix
+--------+--------+---------------+------+-------------------------+
| | FT(011)| Locator | ST | Subscriber bits |
+--------+--------+---------------+------+-------------------------+
/ \
/ \
+----------+------------+--------------------------+
|0000: broadband access subscriber (high priority) |
|0001: broadband access subscriber(medium priority)|
|0010: broadband access subscriber (low priority) |
|0011: broadband access subscriber (low priority) |
|0100: mobile subscriber(high priority) |
|0101: mobile subscriber (medium priority) |
|0110: mobile subscriber (low priority) |
|0111: mobile subscriber (low priority) |
|1001: enterprise |
|1000: enterprise |
|1010: WiFi subscriber |
|1011: WiFi subscriber |
|110-111: Reserved |
+--------------------------------------------------+
Figure 4: ST Value Example
3. Platform Type(PT)
Platform type is to indicate typical service platforms offered by
operators. This field may have scalability problem since there are
numerous types of services in the further . It is recommended that
only aggregated service platform types (e.g. according to service
priority) should be defined in this field. This type of prefix is
usually allocated to service platforms in operator's data center.
One example is shown in the following figure:
Xie, et al. Expires August 29, 2013 [Page 9]
Internet-Draft Semantic use case February 2013
IPv6 Prefix
+--------+--------+---------------+------+-------------------------+
| | FT(001)| Locator | PT | Platform bits |
+--------+--------+---------------+------+-------------------------+
/ \
/ \
+----------+------------+---------------+
|000: high priority service platform |
|001: high priority service platform |
|001: medium priority service platform |
|010: medium priority service platform |
|011: medium priority service platform |
|100: low priority service platform |
|101: low priority service platform |
|110~111: reserved |
+---------------------------------------+
Figure 5: PT Value Example
4. Benifits of Semantic Use Case
The following describes a few benifits (and non-exhaustive) of above
semantic use case for an operator:
1. Easy network device management. With the combinition of FT, NDT
and Locator, network devices from different regions can be easily
identified. Besides, network-based routing policies can also be
enforced with NDT.
2. Bi-directional subscriber quality of service guarantee. Since ST
is consistent with the overall communication process for a
subscriber, bi-directional quality of service guarantee can be
easily achieved for cross-region communication.
3. Fine-Grained user and service control. Normally, ST is located
in the source address of a subscriber, and PT is located in the
destination address for upstream traffic. Therefore, with a
simple combination of ST and PT, fine-Grained service control can
be applied to subscribers (e.g. high priority broadband access
subscriber with high priority service platform).
4. Service-based Routing. With the definition of ST, different
routing policies can be applied according to ST field.
Other requirements listed in section one can also be achieved in this
use case.
Xie, et al. Expires August 29, 2013 [Page 10]
Internet-Draft Semantic use case February 2013
5. IANA Considerations
This document has no actions for IANA.
6. Security Considerations
Embedding semantics in prefix is actually exposing more information
of packets explicit. These informations may also provide convenient
for malicious attackers to track or attack certain type of packets.
When networks announce their local prefix semantics to their peer
networks, it may increase the vulnerable risk.
7. Acknowledgements
Authors would like to show sincere appreciation to Erik Nygren, Joel
Jaeggli, Owen DeLong for their comments and suggestions.
8. References
8.1. Normative References
[I-D.jiang-semantic-prefix]
Jiang, S., Sun, Q., and I. Farrer, "A Framework for
Semantic IPv6 Prefix and Gap Analysis",
draft-jiang-semantic-prefix-04 (work in progress),
January 2013.
[RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768,
August 1980.
[RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and
E. Lear, "Address Allocation for Private Internets",
BCP 5, RFC 1918, February 1996.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
8.2. Informative References
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
Xie, et al. Expires August 29, 2013 [Page 11]
Internet-Draft Semantic use case February 2013
[RFC2661] Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,
G., and B. Palter, "Layer Two Tunneling Protocol "L2TP"",
RFC 2661, August 1999.
[RFC2865] Rigney, C., Willens, S., Rubens, A., and W. Simpson,
"Remote Authentication Dial In User Service (RADIUS)",
RFC 2865, June 2000.
[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.
Authors' Addresses
Chongfeng Xie
China Telecom
Room 708, No.118, Xizhimennei Street
Beijing 100084
P.R. China
Email: sunqiong@ctbri.com.cn
Qiong Sun
China Telecom
Room 708, No.118, Xizhimennei Street
Beijing 100084
P.R. China
Email: bingxuere@gmail.com
Sheng Jiang
Huawei Technologies Co., Ltd
No.156 Beiqing Road
Beijing 100095
P.R. China
Email: jiangsheng@huawei.com
Xie, et al. Expires August 29, 2013 [Page 12]
