Internet DRAFT - draft-khy-rtgwg-central-controlled-ipran
draft-khy-rtgwg-central-controlled-ipran
Routing Area Working Group Katherine Zhao
Internet-Draft Jiehui Hu
Intended status: Informational Huawei Technologies
GuangMing Yong
China Telecom Co.,Ltd
Ning So
TATA Communications
February 10, 2014
Use Cases and Architecture of Central Controlled IP RAN
draft-khy-rtgwg-central-controlled-ipran-01.txt
Abstract
This document introduces the requirements and use cases for IP RAN
(Radio Access Networks). To support the requirements, the document
provides an architecture with centralized control plane as well as
separation of control plane and data plane. The document also
describes techniques for IP RAN network initialization and
construction; interfacing to management plane and third party
applications. This document can be used as a guideline for central
controlled IP RAN design and development.
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 January 06, 2014.
Copyright Notice
Copyright (c) 2013 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
XXX [Page 1]
Internet-Draft Central Controlled IP RAN July 9, 2013
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.
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 . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirement Language . . . . . . . . . . . . . . . . . . 3
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
2. Requirements and use case for central controlled IP RAN . . . 3
2.1. Scenarios of traditional IP RAN . . . . . . . . . . . . . 3
2.2. Requirements of central controlled IP RAN . . . . . . . . 4
2.3. Network structure of central controlled IP RAN . . . . . 5
2.3.1. Mode 1: Integrated Controller . . . . . . . . . . . . 6
2.3.2. Mode 2: Separated Controller for access and
aggregation . . . . . . . . . . . . . . . . . . . . . 7
2.3.3. Mode 3: Separated Controller for access, aggregation
and metro core . . . . . . . . . . . . . . . . . . . 8
2.4. Service carrier requirement for the central controlled IP
RAN . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.4.1. Requirements for the carrier of mobile back haul . . 9
2.4.2. Requirements for the carrier of enterprises and
governments . . . . . . . . . . . . . . . . . . . . 9
3. Central Controlled IR RAN Architecture . . . . . . . . . . . 9
3.1. Reference Architecture . . . . . . . . . . . . . . . . . 9
3.2. Reference Model . . . . . . . . . . . . . . . . . . . . . 11
3.2.1. Built-in IP RAN Control Plane . . . . . . . . . . . . 11
3.2.2. Stand-alone IP RAN Control Plane . . . . . . . . . . 13
3.2.3. Functional Block . . . . . . . . . . . . . . . . . . 15
3.2.4. Interface Definition . . . . . . . . . . . . . . . . 16
3.2.5. Management Plane . . . . . . . . . . . . . . . . . . 17
XXX [Page 2]
Internet-Draft Central Controlled IP RAN July 9, 2013
3.2.6. Forwarding Plane . . . . . . . . . . . . . . . . . . 18
4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18
6. Security Considerations . . . . . . . . . . . . . . . . . . . 18
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 18
7.1. Normative References . . . . . . . . . . . . . . . . . . 18
7.2. Informative References . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction
1.1. Requirement 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].
1.2. Terminology
The following terms are used in this document:
ASG: Aggregation Service gateway
BS: Base station
BSC: Base station controller
CSG: Cell site gateway
CE: Customer Edge
CP-DP: Control Plane and Data Plane interface
IP RAN: IP Radio Access Network
IP RNC: IP Radio network controller
NMG: Network management
MME: Mobile management entity
MPLS: Multi-protocol Label Switching
RSC: Radio service controller
RSG: Radio Service Gateway
SGW: Serving gateway
SR: Service router
VLAN - Virtual Local Area Network
VPN - Virtual private network
2. Requirements and use case for central controlled IP RAN
2.1. Scenarios of traditional IP RAN
IP RAN is mainly used to carry the traffic from 3G, LTE base station
to provide the carrier of high speed service for IP-based mobile back
haul.
XXX [Page 3]
Internet-Draft Central Controlled IP RAN July 9, 2013
The normal topology in IP RAN is based on ring or tree. When L3
service is required in metro, aggregation and access area, IP RAN
usually uses ring topology to form the network.
Fig. 1 shows a typical network topology of IP RAN. There are two
layers: access layer and aggregation layer. The access devices are
the edge of the IP RAN, and are used for the service access; The
aggregation devices are used to aggregate the traffic from access
devices.
The traffic from base station goes via FE/GE to access device. Access
device will establish two redundant pseudowires to two aggregation
devices. Aggregation device will terminate the pseudowires and get
into the L3VPN. Two aggregation devices will work as the gateway for
L3 services, and provide the protection for the base station service.
The service core network element will access the metro core after
the aggregation of CE, and are connected with base station through
L3VPN.
|<-Pseudowire->|<---L3VPN--->|
+--+ +---+ +------+ +------+ +------+
|BS|--|CSG|----| ASG |----------| RSG |---------| BSC |
+--+ +---+ +------+\ / +------+\---- /+------+
| \ / | \ \ /
| \ / | \ \
+--+ +---+ \ / | \ / \ +-------+
|BS|--|CSG| \ | \ -|ATM RSC|
+--+ +---+ / \ | / \ / +-------+
| / \ | / /
| / \ | / / \
+--+ +---+ +------+/ \ +------+/---/ \+------+
|BS|--|CSG|----| ASG |----------| RSG |---------| |
+--+ +---+ +------+ +------+ +------+
IP RNC/S-GW/MME
|<-access->|<-aggregation-->|
Fig. 1 Traditional IP RAN Network Structure
2.2. Requirements of central controlled IP RAN
IP RAN uses the design ideas from flexible IP network communication,
and is based on the architecture of traditional router. It enhances
the OAM mechanism, service protection, and the capability of
XXX [Page 4]
Internet-Draft Central Controlled IP RAN July 9, 2013
multiplexing clock transportation. The routing based hardware
structure has rich L3 routing functions. It can provide the better
multi-service carrier, and support multi-point to multi-point
communication scenario in future mobile network. Compared with
traditional IP metro network, IP RAN solution will focus on the high
availability, simplified operation and management, networking
intelligence and OPEX saving from end to end, etc.
The problems in traditional IP RAN network
Network high availability
IP RAN is based on the traditional IP router platform, it uses
complicated IP and MPLS protocols to construct the network with
huge amount of devices. This is a challenge to the high
availability of network deployment
Complexity of network management
IP RAN deployment usually involves a lot of IP MPLS devices,
this will introduce very complicated issues in network
management and operation. In a typical big metro area, for a
local network with the scale of 10k base stations, we need to
increase the network with 10500 IP/MPLS equipments. The IP
network scale (equipment number) will increase 10 times, and
equipment is distributed divergently. This will cause the
operation pressure to carriers they nerve faced before. In
addition to that, there are many protocols running between
access and aggregation devices, network operators must
understand and memory lot information regarding to protocols
and network structures. It increases the complexity of network
operation, and brings more OPEX to carriers.
Low intelligence in network
The time gaps in the mobile network evolving from 2G to 3G and
to 4G are decreasing. New value added service and application
keep coming up. The question about how to quickly deploy new
service and establish the dynamic maintenances will bring in
more harsh technical requirements to traditional IP RAN.
Using the architecture of central control, separation of control
plane and forwarding plane, open and programmability, we can find out
the solution for the network high availability, complexity of
operation and management, network intelligence.
2.3. Network structure of central controlled IP RAN
XXX [Page 5]
Internet-Draft Central Controlled IP RAN July 9, 2013
The network structure of central controlled IP RAN is illustrated in
Fig. 2 to Fig. 4. The network is still layered as access and
aggregation layers. There is central controller to provide the
control capability of topology discovery, path calculation and
service establishment. There are three modes for central controller,
one is built-in controller mode and other two are separated
controller mode but for different scope of network. Details for these
models and architectures are given in section 3 of the same document.
2.3.1. Mode 1: Built-in Controller
For this mode, the controller is integrated into aggregation routers.
There may be multiple controller in a IP RAN.
*********<-----Built-in Controller Running on ASG
+--+ +---+ * +---+ *
|BS|---|CSG|---|ASG|\*
+--+ +---+ * +---+ \
| * | *\
+--+ +---+ ********* \
|BS|---|CSG| | \
+--+ +---+ | \
| ********* \
+--+ +---+ * +---+ * \ +-----+ +------+
|BS|---|CSG|---|ASG| * \| RSG |---------| BSC |
+--+ +---+ * +---+\* /+-----+\---- /+------+
* \ / | \ \ /
*********\ / | \ \
\ / | \ / \ +-------+
\ | \ -|ATM RSC|
/ \ | / \ / +-------+
*********/ \ | / /
* / \ | / / \
+--+ +---+ * +---+/* \+-----+/---- \+------+
|BS|---|CSG|---|ASG| * /| RSG |---------| |
+--+ +---+ * +---+ * / +-----+ +------+
| * | * / IP RNC/S-GW/MME
+--+ +---+ ********* /
|BS|---|CSG| | /
+--+ +---+ | /
| *********/
+--+ +---+ * +---+ /
|BS|---|CSG|---|ASG|/*
+--+ +---+ * +---+ *
* *<-----Built-in Controller Running on ASG
*********
Fig. 2 IP RAN Mode 1: Built-in Controller running on ASG
XXX [Page 6]
Internet-Draft Central Controlled IP RAN July 9, 2013
2.3.2. Mode 2: Stand-alone Controller for Access and Aggregation
For this mode, the stand-alone central controller is used. The
control functions in access and aggregation devices are moved to the
controller server named IPRAN-CP in this document. In such a way,
the access and aggregation devices are only responsible for the
forwarding. The controller can control multiple aggregation and
access devices.
+----------+
| |
*****************-------| IPRAN-CP |
+--+ * +---+ +---+ * | |
|BS|---|CSG|---|ASG|\* +----------+
+--+ * +---+ +---+ \
* | | *\
+--+ * +---+ | * \
|BS|---|CSG| | * \
+--+ * +---+ | * \
* | | * \
+--+ * +---+ +---+ * \ +-----+ +------+
|BS|---|CSG|---|ASG| * \| RSG |---------| BSC |
+--+ * +---+ +---+\* /+-----+\---- /+------+
* \ / | \ \ /
* *\ / | \ \
* * \ / | \ / \ +-------+
*controlled area* \ | \ -|ATM RSC|
* * / \ | / \ / +-------+
* */ \ | / /
* / \ | / / \
+--+ * +---+ +---+/* \+-----+/---- \+------+
|BS|---|CSG|---|ASG| * /| RSG |---------| |
+--+ * +---+ +---+ * / +-----+ +------+
* | | * / IP RNC/S-GW/MME
+--+ * +---+ | * /
|BS|---|CSG| | * /
+--+ * +---+ | * /
* | | */
+--+ * +---+ +---+ /
|BS|---|CSG|---|ASG|/*
+--+ * +---+ +---+ *
* *
*****************
Fig.3 IP RAN Mode 2: Stand-alone Controller Controls CSG and ASG
XXX [Page 7]
Internet-Draft Central Controlled IP RAN July 9, 2013
2.3.3. Mode 3: Stand-alone Controller for Access and Aggregation
For this mode, the stand-alone central controller is used too. The
difference from the mode 2 is that the controller will control the
access and aggregation layers include RSG. This mode can provide the
control capability from end to end.
+----------+
| |
**********************************-------| IPRAN-CP |
+--+ * +---+ +---+ * | |
|BS|---|CSG|---|ASG|\ * +----------+
+--+ * +---+ +---+ \ *
* | | \ *
+--+ * +---+ | \ *
|BS|---|CSG| | \ *
+--+ * +---+ | \ *
* | | \ *
+--+ * +---+ +---+ \ +-----+ * +------+
|BS|---|CSG|---|ASG| \| RSG |---------| BSC |
+--+ * +---+ +---+\ /+-----+\---- /+------+
* \ / | \* \ /
* \ / | \ \
* \ / | *\ / \ +-------+
* \ | * \ -|ATM RSC|
* / \ | */ \ / +-------+
* / \ | / /
* / \ | /* / \
+--+ * +---+ +---+/ \+-----+/---- \+------+
|BS|---|CSG|---|ASG| /| RSG |---------| |
+--+ * +---+ +---+ / +-----+ * +------+
* | | / * IP RNC/S-GW/MME
+--+ * +---+ | / *
|BS|---|CSG| | / *
+--+ * +---+ | / *
* | | / *
+--+ * +---+ +---+ / *
|BS|---|CSG|---|ASG|/ *
+--+ * +---+ +---+ *
* controlled area *
**********************************
Fig.4 IP RAN Mode 3: Stand-alone Controller controls from CSG to RSG
XXX [Page 8]
Internet-Draft Central Controlled IP RAN July 9, 2013
2.4. Service Carrier Requirement for Central Controlled IP RAN
The central controlled IP RAN must satisfy two major categories of
requirements for services. One is for mobile back haul and another
one is for enterprises and governments. Services include Ethernet,
ATM and TDM.
2.4.1. Requirements for the Carrier of Mobile Backhaul
1 Support the access of IP and Ethernet, provide the high
available, high throughput carrier for the traffic of mobile
back haul
2 Provide the carrier for LTE network, support the flexible
access between base stations, multi-home base station, and the
carrier of multicast traffic for base stations
3 Provide the power monitoring, integrated network management for
different systems of access services
2.4.2. Requirements for the carrier of enterprises and governments
1 Provide the high available, high throughput carrier for the
access of L2/L3 VPN services, it includes P2P, P2MP and MP2MP
tunnels
2 Support the access of high bandwidth Internet leased line,
circuit emulation, access of ATM/FR/TDM
XXX [Page 9]
Internet-Draft Central Controlled IP RAN July 9, 2013
3. Central Controlled IR RAN Architecture
3.1. Reference Architecture
+----------+ +----------+
| Third | |Network |
| Party App| |Management|
+----------+ +----------+
\ / |
\ / |
+--------+ to NMG interfaces
|IPRAN-CP| on network devices
+--------+
/ | | \
/ | | \
........../.....|...|....\.............
. +----+-----+ | | +----+-----+ .
+----+ . |Base|Cntl | | | |Base|Cntl | .
| BS |----.--|Rtg |Agent|-|---|---|Rtg |Agent|\ .
+----+ . |----------| | | |----------| \.
. |Frwd Node1| | | |Frwd Node2| \
. +----------+ | | +----------+ .\
. / \ . \+--------+
. / \ . /|RNC/SGW/|
. +----+-----+ +----+-----+ ./ |MME/BSC |
+----+ . |Base|Cntl | |Base|Cntl | / +--------+
| BS |----.---Rtg |Agent| |Rtg |Agent| /.
+----+ . |----------| |----------| / .
. |Frwd Node1| |Frwd Node2|/ .
. +----------+ +----------+ .
. Central|Controlled Area | .
.........|..................|..........
| |
.....................|..................|...............
TDM/ATM/Ethernet | MPLS | TDM/ATM/Ethernet
Fig 5. Central Controlled IP RAN Architecture
Above is the central controlled IP RAN architecture, where the
control plane is separated from the forwarding plane and moved to an
independent entity named IPRAN-CP (IP RAN Control Plane) in this
document.
IPRAN-CP, IP RAN Control Plane, is a software system that can be
XXX [Page 10]
Internet-Draft Central Controlled IP RAN July 9, 2013
deployed either in a network device or a separate computer server.
IPRAN-CP controls the entire IP RAN network domain, the size of the
domain can be defined by Network Operator based on the actual network
planning and use cases. IPRAN-CP controls the IP RAN network based
on the network topology, actual states and status, which are operated
by the network administrator.
IPRAN-CP provides northbound interface to network management system
used for service deployment, monitoring, troubleshooting, fault
location, and other functions. Netconf could be one of the option
for northbound interface implementation. The northbound interface of
IPRAN-CP is different from the traditional network equipment
interfaces. It is based on the network view and virtual interfaces.
IPRAN-CP can provide the interface to network topology and operate on
a virtual network.
At the same time, IPRAN-CP also opens to third-party application,
allows third party to use RESTful API to program and control network
devices. Through IPRAN-CP, Third-party applications can utilize the
access to network resources (such as network topology), deliver
network diagnosis, fault location, application performance
monitoring, add innovative applications in the future and so on.
Because the control plane has been separated out, the network devices
become forwarding nodes in the IP RAN domain. Forwarding nodes still
keep the basic routing functions in order to establish control and
management channel between IPRAN-CP/NMG and all the forwarding nodes.
Other control functionality is moved to IPRAN-CP, the forwarding node
no longer has the control plane functions (such as protocols needed
for establishing services). Forwarding node accepts network resources
and states from the controller via Control Agent module and reports
itself (such as ports) to the controller.
Forwarding nodes still need traditional northbound managemnent
interface. However northbound interface features of the network
services and the protocol are no longer included. Instead only a
small subset of the features such as power supplies, voltages,
veneers and other management features are remained on the network
devices. The forwarding plane continues to maintain the existing
schema using IP/MPLS forwarding.
3.2. Reference Model
According to different use cases and scenarios, typical reference
model can be either in built-in model or stand-alone model. Where the
stand-alone model can be divided into another two different sub
models
XXX [Page 11]
Internet-Draft Central Controlled IP RAN July 9, 2013
3.2.1. Central Controlled IP RAN in Built-in Model
.....................................
. +----+-----+ .
+----+ . |Base|Cntl | +----------+ . +----+-----+
| BS |-I1-----|Rtg |Agent|-I2--|Central-CP| . |Base|Cntl |
+----+ . |----+-----| |----------|----I4-|Rtg |Agent|
. | CSG 1 |-----| ASG 1 | . |----+-----|
. +----------+\ /+----------+ . | RSG 1 |
. \ / . +----------+
. * I3 .
. / \ .
. +----+-----+/ \+----------+ . +----+-----+
+----+ . |Base|Cntl |-----|Central-CP| . |Base|Cntl |
| BS |-I1-----|Rtg |Agent| |----------| . |Rtg |Agnet|
+----+ . |----+-----|-I2--| ASG 2 |---I4--|----+-----|
. | CSG 2 | +----------+ . | RSG 2 |
. +----------+ . +----------+
. .
. Central Controlled Domain .
.....................................
Fig 6. Central Controlled IPRAN in Built-in Model
Like the one above in an IP RAN network, IPRAN-CP functionality is
built into aggregation service gateway ASG, in which an ASG controls
a group of CSGs connected to it. IPRAN-CP functionality is
integrated with ASG that retains its original aggregation features.
The original control functionality on CSG is moved up to ASG. The ASG
with built-in IPRAN-CP controls the forwarding behavior of CSG. CSG
retains basic routing functions for establishing the communication
channel with management plane and control plane. CSG communicates
with IPRAN-CP through a control agent running on CSG, the agent
performs status reporting and accepts control information distributed
by the central control plane residing on ASG.
In this reference model, an IP RAN domain can have more than one ASG,
every ASG has a built-in IPRAN-CP. A CSG can be controlled by a
single or multiple(in ring structure) ASG(s). In case there are two
or more ASGs, one ASG works as master controller, and the other one
works as alternative backup. IPRAN-CP can also do load-balancing.
In case of CSG redundancy, each active and standby can be controlled
by different ASG.
XXX [Page 12]
Internet-Draft Central Controlled IP RAN July 9, 2013
IPRAN-DP supports the network virtualization capabilities, internal
CSG topology of an IP RAN is not visible to external network. For
external routing device, it only establishes routing neighbor with
ASG, and believes that only the ASG routes while the CSG routes are
invisible. External routing equipment can considered an IPRAN-CP
controlled domain is a big virtual router.
Using built-in mode, the one can use the existing network equipment
to perform software upgrades, apply the new control technology in the
access network. Changes to the network architecture and network
management model can be limited to small. It is a good strategy to
conduct the rapid deployment of central controlled IP RAN.
3.2.2. Central Controlled IP RAN in Stand-alone Model
Built-in IPRAN-CP is easy of deployment and takes advantage of
existing network structure, equipments and other investment. However
because there is no separation of control plane and forwarding plane
on the existing device that IPRAN-CP attached to, for example ASG,
the control ability, network performance and the domain scope are
limited by the capability of the existing aggregation equipment ASG
and its attached network structure.
Stand-alone IPRAN-CP model is designed to resolve above issue. It
deploys IPRAN-CP with stand-alone computer server(s) or other IT
hardware to eliminate the physical limitation of ASG. The stand-
alone control server can use the commodity product with much stronger
CPU power and process ability. The controller no longer participates
in the forwarding of network traffic like ASG does; it can be located
in a remote data center without geographical limitation thus it is
able to control more and more network nodes in different locations.
Therefore stand-alone IPRAN-CP can provide higher scalability and
batter performance.
XXX [Page 13]
Internet-Draft Central Controlled IP RAN July 9, 2013
+---------+
|IPRAN-CP |
+---------+
/I3 |I3| \I3
/ | | \
........../......|..|.....\...........
. +----+-----+ | | +----+-----+ . +----+-----+
+----+ . |Base|Cntl | | | |Base|Cntl | . |Base|Cntl |
| BS |-I1--|Rtg |Agent|--|I2|--|Rtg |Agent|---I4-|Rtg |Agent|
+----+ . |----------| | | |----------| . |----------|
. | CSG 1 | | | | ASG 1 | . | RSG 1 |
. +----------+ | | +----------+ . +----------+
. / \ .
. / \ .
. +----+-----+ +----+-----+ . +----+-----+
. |Base|Cntl | |Base|Cntl | . |Base|Cntl |
+----+ . |Rtg |Agent| |Rtg |Agent| . |Rtg |Agent|
| BS |-I1--|----------|---I2--|----------|---I4--|----------|
+----+ . | CSG 2 | | ASG 2 | . | RSG 2 |
. +----------+ +----------+ . +----------+
. IP RAN Domain .
......................................
-------------------------------------------------------------------
+---------+
| IP RAN |---------------+
| CP | |
+---------+------------+ |
/I3 |I3| \I3 |I3|
/ | | \ | |
........../......|..|.....\.........|..|................
. +----+-----+ | | +----+-----+ | | +----+-----+ .
+----+ . |Base|Cntl | | | |Base|Cntl | | +-|Base|Cntl | .
| BS |-I1--|Rtg |Agent|--|--|--|Rtg |Agent|-|----|Rtg |Agent| .
+----+ . |----------| | | |----------| | |----------| .
. | CSG 1 | | | | ASG 1 | | | RSG 1 | .
. +----------+ | | +----------+ | +----------+ .
. / \ | .
. / \ | .
. +----+-----+ +----+-----+ | +----+-----+ .
+----+ . |Base|Cntl | |Base|Cntl | +----|Base|Cntl | .
| BS | . |Rtg |Agent| |Rtg |Agent| |Rtg |Agent| .
+----|-I1--|----------|---I2---|----------|---I4-|----------| .
. | CSG 2 | | ASG 2 | | RSG 2 | .
. +----------+ +----------+ +----------+ .
. IP RAN Domain .
........................................................
XXX [Page 14]
Internet-Draft Central Controlled IP RAN July 9, 2013
Fig 7. Central Controlled IP RAN in Stand-alone Model
Above diagram shows a use case of stand-alone IP RAN control plane.
Where IPRAN-CP software is pulled out from ASG and running on a
separate computer server (or in a proprietary device, this document
follow-up to the server instead). The servers do not participate in
the forwarding of network traffic. The network devices to be
controlled by IPRAN-CP can be vary depending on the scope of the
actual needs. You can only control access layer equipment, or you can
also control the devices include both access layer and aggregation
layer.
Different from built-in IPRAN-CP on ASG, a stand-alone control plane
can control and manage many CSGs as well as ASG itself, or more than
one ASGs with CSGs connected to them. If needed, it can also control
even RSGs in an extended IP RAN domain. In this use case, CSG, ASG
as well as RSG are integrated with a Control Agent module. Control
Agent is responsible for reporting topology, states and statistics to
IPRAN-CP; and receiving control information and forwarding tables
from IPRAN-CP. The network devices include CSG, ASG and RSG keep
basic routing functions for establishing control channel and
management channel so that IPRAN-CP can use CP-DP (control plane and
data plane) protocol to control these devices.
IPRAN-CP needed to support network virtualization functions, from the
view of the external network devices, this IPRAN domain is just a
single logical router. If any forwarding device (for example CSG)
within the domain has communicated with external network nodes using
traditional routing protocol such as BGP,IGP,LDP or RSVP, the central
controlled IPRAN-CP must support the same communication channel and
support the same routing protocols on behalf of the forwarding
devices.
3.2.3. Functional Block
This section describes the functions and features to be supported by
the control plane and forwarding plane respectively.
The functions of IPRAN-CP:
o CP-DP control protocol features: provide forwarding device control
information; establish and maintain connections between control
plane and the forwarding nodes. CP-DP protocol can be XMPP,
Openflow, or a newly defined protocol.
XXX [Page 15]
Internet-Draft Central Controlled IP RAN July 9, 2013
o Network resource management features: discover and collect the
forwarding nodes, the ports on the nodes as well as topology
resources in the IP RAN domain. Other software modules can use
the resource collection to calculate path, deploying services, and
build forwarding tables etc. IPRAN-CP should also open to network
management applications and third-party applications to programm
and manage the network resources.
o Network virtualization features: abstract network and shield the
physical network details from the service layer. Operational
service deployment can be done based on virtual network without
concernning how forwarding path for the virtual network to get
through at the lower layer. In IP RAN, the transport uses MPLS,
the network virtualization here means MPLS virtualization.
o Network protocol layer: provides traditional routers supported
conventional routing protocol stack, which was running on the
forwarding nodes. Now these features are moved up to the central
controller.
o Network service layer: Supports IP RAN required L2VPN and L3VPN
services. L2VPN including VPWS and VPLS.
o Supporting module: provides basic tools include fault location,
alarm, northbound interface for maintenance and management
capabilities.
The functions of forwarding node:
o Basic routing features: run IGP routing protocol and responsible
for establishing connectivity with other devices, setup routes and
collect topology. It must be done before a controller can
communicate with the network devices.
o Control protocols: corresponds to the control protocol running on
the IPRAN-CP device, responsible for establish and maintain CP-DP
connection.
o Control Agent: Responsible for the registration with IPRAN-CP;
reporting its information to the controller; accepting control
information and forwarding tables distributed by the IPRAN-DP.
Control Agent is also responsible to install the forwarding tables
to the data plane that is used to guide the traffic forwarding.
o Forwarding Plane: forwarding and procession of messages and user
traffics.
XXX [Page 16]
Internet-Draft Central Controlled IP RAN July 9, 2013
o Support module: provides debug and diagnostics functions on
forwarding nodes; supports device management features; provides
interface to network management (include power supplies, voltages,
etc).
3.2.4. Interface Definition
The interfaces given on above diagrams (refer to Fig 7) are described
at below.
o I1: Interface between base station and forwarding node. It keeps
traditional IP RAN network and base station interface, remains no
change.
o I2: Interface between forwarding nodes.
* Forwarding nodes run extended ISIS for topology advertisements
between nodes. ISIS has been widely used in the existing IP
RAN networks to flood link and node information, therefore,
ISIS can be leveraged for central controlled IP RAN as part of
the topology collection and flood protocol.
* With built-in model, because IPRAN-CP is running on an existing
network devices such ASG, ISIS is running directly between the
ASG and the CSG, IPRAN-CP on ASG can get topology information
from ISIS directly.
* With stand-alone model, because SDN IPRAN-CP may be deployed
outside of the actual physical network, the control plane
cannot communication with forwarding plane via ISIS directly.
In this case, a selected topology collection agent in the
network will be needed. The agent gathers network topology
information from CSGs through ISIS protocol, and then reports
the information to IPRAN-CP through a CP-DP protocol. An IP
RAN may have very large number of network nodes, while the
ability of access equipment is limited. Hence it could be
required to divide a IP RAN network into smaller ISIS domains
to match the capacity of the access equipment. The topology
collection agent usually is located at ASBR node of ISIS such
as ASG.
o I3: Interface between IPRAN-CP and forwarding devices. This
interface needs to run a CP-DP protocol for the forwarding node's
registration, information reporting, and accepting the control
information. Options of the CP-DP protocols could be XMPP,
OpenFlow or a newly defined protocols. This interface is beyond
scope thus left out of this document.
XXX [Page 17]
Internet-Draft Central Controlled IP RAN July 9, 2013
o I4: Interface between IPRAN-CP and external router. It supports
conventional routing protocols such as BGP,ISIS,RSVP and LDP etc.
o I5: Interface between RSG and base station controllers. It
remains unchanged. (I5 and BSC are not shown on Fig 7 due to space
limitation)
3.2.5. Management Plane
IPRAN-CP needs to provide northbound interface used for network
management and OSS integration. At the same time, IPRAN-CP needs to
provide an open programming interface used for third-party
application integration and development. For example, when a third-
party monitoring application caught a situation of packet dropping
and link quality degradation along a path, they can use programming
interfaces of IPRAN-CP to control the path and switch to an
alternative path. The northbound interface provided by IPRAN-CP can
be divided into the following categories:
o Policy control interface, including routing policy, ACL etc.
o The service interface, including L2VPN,L3VPN etc.
o Path control interface, including control of the forwarding path,
switching over, definition of bandwidth constraints etc.
o Monitoring interface, including fault events, network quality
threshold, system status monitoring, and statistics etc.
o Resource interfaces, including bandwidth, network topology, tag
resources, interface resources etc.
o Diagnostic tools, such as ping, tracert, NQA etc.
Forwarding nodes also have a light network management plane. The
management uses VPN channel separated from CP-DP channel to manage
the forwarding node. Because forwarding node's control plane has
been moved up to IPRAN-CP, therefore management functionality
provided by the forwarding nodes, are only themselves the equipment
management features as follows:
o Equipment upgrades
o Device management protocols, such as SNMP, Telnet, and FTP etc
o Port management
XXX [Page 18]
Internet-Draft Central Controlled IP RAN July 9, 2013
o Device power, voltage, single-board hardware management features
such as alarms, veneer restarts.
o Environmental monitoring of the device, such as temperature alarms
etc.
3.2.6. Forwarding Plane
Forwarding IP/MPLS forwarding service.
4. Acknowledgements
We would like to thank Lin Han and Guoyi Chen who provided valuable
contribution to this document.
5. IANA Considerations
This draft requires no changes in IANA specification,
6. Security Considerations
This draft does not add any additional security implications to IP
RAN networks. All existing authentication and security mechanisms
still apply.
7. References
7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
7.2. Informative References
Author's Address
Katherine Zhao
Huawei Technologies
2330 Central Expressway
Santa Clara, CA 95050
USA
Email: Katherine.Zhao@huawei.com
XXX [Page 19]
Internet-Draft Central Controlled IP RAN July 9, 2013
Jiehui Hu
Huawei Technologies
Huawei Building, No.156 Beiqing Rd.
Z-park ,Shi-Chuang-Ke-Ji-Shi-Fan-Yuan,
Hai-Dian District , BEIJING 100095
P.R.CHINA
Email:hujiehui@huawei.com
GuangMing Yang
Guangzhou Research Institute of China Telecom Co.,Ltd.
109 West Zhongshan Ave,
Tianhe District, Guangzhou,510630
P.R.China
Email: yanggm@gsta.com
Ning So
TATA Communications
2613 Fairbourne Cir.,
Plano, Texas 75093
USA
email: ning.so@tatacommunications.com
XXX [Page 20]
