ISP Semantic use case
draft-sun-semantic-usecase-00
The information below is for an old version of the document.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Qiong Sun | ||
| Last updated | 2012-10-15 | ||
| Stream | (None) | ||
| Formats | plain text htmlized pdfized bibtex | ||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-sun-semantic-usecase-00
Network Working Group C. Xie
Internet-Draft Q. Sun
Intended status: Informational China Telecom
Expires: April 18, 2013 October 15, 2012
ISP Semantic use case
draft-sun-semantic-usecase-00
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 April 18, 2013.
Copyright Notice
Copyright (c) 2012 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
Xie & Sun Expires April 18, 2013 [Page 1]
Internet-Draft Semantic use case October 2012
(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
2.1. Guidelines to define the semantic bits . . . . . . . . . . 4
2.2. Typical types of semantics . . . . . . . . . . . . . . . . 5
2.3. How to determine the placement of semantics bits . . . . . 6
2.4. Semantic Design Example . . . . . . . . . . . . . . . . . . 6
3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7
4. Security Considerations . . . . . . . . . . . . . . . . . . . . 7
5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7
6.1. Normative References . . . . . . . . . . . . . . . . . . . 7
6.2. Informative References . . . . . . . . . . . . . . . . . . 7
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8
Xie & Sun Expires April 18, 2013 [Page 2]
Internet-Draft Semantic use case October 2012
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.
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. Device management
In order to achieve easy management for network devices, operators
will usually apply a simple numbering policy for network devices.
Besides, special-purpose security policies may be taken for devices
other than from customers and service platforms. As a result,
seperated address space for network device will help to identify the
network device among numours addresses and apply policy according.
2. Differentiated user management
In operator's network, different kinds of customers may have
different priorities. 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.
3. 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 subscribers.
4. Security Control
Xie & Sun Expires April 18, 2013 [Page 3]
Internet-Draft Semantic use case October 2012
For security requirement, operators need to take control and identify
of certain devices/customers in a quick manner.
5. 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.
2. How to design the semantic bits
The embedded semantic bits should be carefully designed since they
are limited resources allocated to operators. In this section, we
discuss the guidelines for operators to define the semantic bits,
typical types of semantics, considerations on the placement of
semantics bits, and also give an example to illustrate our
considerations.
2.1. Guidelines to define the semantic bits
Depending on the IPv6 address space that network operators received
from IANA or upstream network service providers, the number of
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:
1. 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.
2. The number of semantics should be limited. According to the
above analysis, the number of semantic bits left for operators is
quite limited. Therefore, it is recommended network operator
Xie & Sun Expires April 18, 2013 [Page 4]
Internet-Draft Semantic use case October 2012
only use necessary semantics when they can bring benefits to
network operations, especially IP-layer policy, e.g. policy
routing, access control and filtering, QoS, network measurement,
etc. The network operators should be very careful to plan and
manage the semantic field. The network operators should self-
restrict NOT to put too many semantic into prefix. So that they
may avoid trap themselves into very complicated management
issues.
3. Semantic overlap should be avoided for packet. Any potential
scenarios that a given packet may be mapped two or more semantic
prefixes are considered harmful. And for each individual
semantic, it is also recommended that one device/host can only
belong to one semantic.
4. The design of semantic bits should be scalable and stable from
the long-term. It should reflect the general potential network
policies in the future and should be defined in highly abstracted
way since there might be quite a lot of unknown emerging
services.
5. Different size of addressing space should be planned carefully
for different sementics. Since different semantics usually
consumes different size of address space, operators should plan
the size of address space according to the service model for
different semantics.
2.2. Typical types of semantics
The typical types of semantics for operators are listed as follows:
1. Device type: indicating network device, subscriber or service
platform, etc.
2. Subscriber type: indicating different types of subscribers for
operators, e.g. broadband access subscriber, mobile access
subscriber, enterprise, WiFi, etc. 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.
3. Service type: indicating typical services offered by operators.
This field may have scalbility problem since there are numerous
types of services in the further. It is recommended that only
aggregated service types (e.g. according to service priority)
should be defined in this field.
Xie & Sun Expires April 18, 2013 [Page 5]
Internet-Draft Semantic use case October 2012
2.3. How to determine the placement of semantics bits
The placement of semantic bits should be carefully designed.
Specifically, based on the usage of semantics, we can further divide
the type of semantics into local-semantic and global-semantic. The
local-semantic is only used within one operator, while global-
semantic can be distributed among different operators. For example,
for the above semantics, device type can be regarded as a global-
semantic which can be used by other operators to do access control or
filtering, and can be distributed via global routing system.
However, subscriber type and service type only concerns with the
service model within one operator.
It is recommended that global-semantic fields should be placed in the
most left bits of the prefix so that different operators may control
the prefix simplier. The locator function should be placed in the
lower place followed by local-semantics.
2.4. Semantic Design Example
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IANA assigned block |Global-S| locator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| locator (Cont.) | Local-Semantic|Subscriber bits|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: Semantic Design Example
The above figure represents an ISP semantic prefix example.
In this example, the semantic prefix domain have a /20 IPv6 address
space. It should serve over one million users. Then 4 bits are
allocated to global-semantics bits to indicate the type of device.
The next 24 most- left bits are allocated as locator. It serves
network aggregation of topology based. The 8 most- right bits are
subscriber bits. It means /56 prefix is assigned to subscribers. 8
bits (from bit 44 to 51) are assigned as local semantic field.
A further detailed example, combing user type, service type, VPNs,
and application virtual overlay networks, the local-semantic field
can be assigned like blow (presented in octet):
00 Normal individual user with normal internet access services
01 High-end individual user with normal internet access services
Xie & Sun Expires April 18, 2013 [Page 6]
Internet-Draft Semantic use case October 2012
02 High-end individual user with secure internet access services
03~07 Reserved
3. IANA Considerations
4. Security Considerations
TBD
5. Acknowledgements
TBD
6. References
6.1. Normative References
[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.
6.2. Informative References
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[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.
Xie & Sun Expires April 18, 2013 [Page 7]
Internet-Draft Semantic use case October 2012
[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: sunqiong@ctbri.com.cn
Xie & Sun Expires April 18, 2013 [Page 8]