ISP Semantic use case
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]