Internet DRAFT - draft-kh-spring-ip-ran-use-case
draft-kh-spring-ip-ran-use-case
SPRING WG B. Khasnabish
Internet-Draft ZTE TX Inc.
Intended status: Informational F. Hu
Expires: May 14, 2015 ZTE Corporation
L. Contreras
Telefonica I+D
November 10, 2014
Segment Routing in IP RAN use case
draft-kh-spring-ip-ran-use-case-02.txt
Abstract
Segment Routing (SR) leverages the source routing paradigm. An
ingress node steers a packet through a controlled set of
instructions, called segments, by pre-pending the packet with an SR
header. A segment can represent any instruction, topological or
service-based. A segment can have a local semantic to an SR node or
global within an SR domain. SR allows one to enforce a flow through
any topological path and service chain while maintaining per-flow
state only at the ingress node of the SR domain. This document
introduces the segment routing in IP Radio Access Network (IP RAN,
mobile backhaul network) use case. Additional requirements to
support segment routing in the IP RAN scenarios are discussed.
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 May 14, 2015.
Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved.
Khasnabish, et al. Expires May 14, 2015 [Page 1]
Internet-Draft SR IP RAN use case November 2014
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Abbreviations . . . . . . . . . . . . . . . . 3
3. IP RAN Network Architecture . . . . . . . . . . . . . . . . . 3
3.1. IP RAN Network Scenario . . . . . . . . . . . . . . . . . 3
3.2. Requirements for IP RAN network . . . . . . . . . . . . . 4
4. Benefit for segment routing in IP RAN network . . . . . . . . 5
5. Unified Service Deployment . . . . . . . . . . . . . . . . . 6
5.1. Requirement for Control Node . . . . . . . . . . . . . . 8
5.2. Requirement for Forwarding Node . . . . . . . . . . . . . 8
5.2.1. Forwarding Node Structure . . . . . . . . . . . . . . 8
6. Security Considerations . . . . . . . . . . . . . . . . . . . 9
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
9. Normative References . . . . . . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction
Segment Routing (SR) leverages the source routing paradigm. An
ingress node steers a packet through a controlled set of
instructions, called segments, by pre-pending the packet with an SR
header. A segment can represent any instruction, topological or
service-based. A segment can have a local semantic to an SR node or
global within an SR domain. Segment Routing allows one to enforce a
flow through any topological path and service chaining while
maintaining per-flow state only at the ingress node to the Segment
Routing domain
The Segment Routing architecture is described in
([I-D.filsfils-rtgwg-segment-routing]) The Segment Routing control
plane is agnostic to the data plane, and hence it can be applied to
both MPLS (and its many variants) and IPv6.
Seamless MPLS([I-D.ietf-mpls-seamless-mpls])describes an architecture
which can be used to extend MPLS networks to integrate access and
core/aggregation networks into a single MPLS domain. It provides a
Khasnabish, et al. Expires May 14, 2015 [Page 2]
Internet-Draft SR IP RAN use case November 2014
highly flexible and a scalable architecture and the possibility to
integrate hundreds of thousands of nodes.
This document describes the possibility of applying the segment
routing technology to the IP RAN scenario. The segment routing could
simplify the network complexity in case of IP RAN. LDP and RSVP-TE
signaling protocols are not required, and the end-to-end service
deployment can be achieved very easily.
2. Conventions and Abbreviations
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 [RFC2119].
The following notations and abbreviations are used throughout this
draft.
o ASG: Aggregation Site/Service Gateway
o BS: Base Station
o CSG: Cell Site Gateway
o FRR: Fast Re-Routing
o IP RAN: Internet Protocol RAN
o LTE: Long Term Evolution
o RAN: Radio Access Network
o RNC: Radio Network Controller
o RSG: Radio Service Gateway
o SR: Segment Routing
3. IP RAN Network Architecture
3.1. IP RAN Network Scenario
Khasnabish, et al. Expires May 14, 2015 [Page 3]
Internet-Draft SR IP RAN use case November 2014
----------------
/ \
/ \
+------+ +----+ +----+ +----+ +----+
| BS |---|CSG1| |ASG1|-------|RSG1|-----|RNC1|
+------+ +-+--+ +----+ +----+ +----+
| Access | Aggregation |
| Domain | Domain |
+------+ +-+--+ +----+ +----+ +----+
| BS |---|CSG2| |ASG2|----- -|RSG2|-----|RNC2|
+------+ +----+ +----+ +----+ +----+
\ /
\ /
--------------
Figure 1: IP RAN Network Scenario
A typical mobile backhaul network is shown as figure 1. In the
mobile backhaul network, being different from the typical access
devices(DSLAM, MSAN), CSGs and RSGs of the mobile backhaul network
needs to support rich MPLS features such as path design, protection
switch, OAM, etc.
3.2. Requirements for IP RAN network
(1) End-to-end transport LSP: MPLS based forwarding SHALL be
provided by the Seamless MPLS based infrastructure between any
nodes. The MPLS based service could be setup by L3VPN, L2VPN or
pseudo wire.
(2) OAM: The Seamless MPLS architecture should propose unified OAM
mechanisms to satisfy the requirements of the end-to-end
services.
(3) Protection: The protection switch mechanism has been provided in
IP RAN network to achieve convergence in 50 ms.
(4) Scalability: With the proliferation of 3G/LTE, more and more
node-Bs are deployed. IP/MPLS equipment in IP RAN network are
very huge. In addition, there is more complex configuration for
IP RAN network, because of the richer MPLS TE properties/
features requirements. So there is more challenge in scaling
the IP RAN network.
(5) Security: The session security should be better or at least as
good as in traditional IP/MPLS network.
Khasnabish, et al. Expires May 14, 2015 [Page 4]
Internet-Draft SR IP RAN use case November 2014
(6) Survivability: The survivability should be better or at least as
good as in traditional IP/MPLS network.
(7) Flexibility and Overheads: The additional overheads, if any, due
to using SR should be offset by the flexibility provided by the
SR in IP RANs.
(8) Reduction configuration for CSGs and ASGs: The number of CSGs
and ASGs in the IP RAN domain are very huge now, and with the
increase of mobile Internet traffic, more CSGs could be added to
the Access Domain, and CSGs could be installed in wide area.
There is a great need to do little or no configuration on CSGs
to avoid configuration operation.
4. Benefit for segment routing in IP RAN network
(1) Simplify end-to-end LSP tunnel establishment: The data plane in
IP RAN network is MPLS based forwarding. Segment routing
technology is based on MPLS data plane, and there is no change
for MPLS forwarding, so the data plane in IP RAN could use the
segment routing forwarding technology. Segment routing simplify
the control plane by IGP protocol distribution, there is no need
for RSVP-TE and LDP signaling protocol. RSVP-TE, LDP protocol
usually run in an AS, while IP-RAN network may cross AS domains.
Therefore the cross-AS issue should be considered in the IP-RAN,
and this is a very complex issue. Segment routing uses IGP
protocol to distribute SID, and hence there is no cross-AS issue
for segment routing. The BGP protocol could be extended to
distribute SID in
([I-D.gredler-idr-bgp-ls-segment-routing-extension]) SR as well.
The segment routing technology can simplify end-to-end LSP
tunnel establishment.
(2) Network virtualization: Service chaining could be introduced
into SR domain. An SR header could be used to carry the set of
forwarding or services that need to be applied to the packet.
This can be achieved by creating an SR header with the desired
sequence of service IDs that need to be applied to the packet.
(3) Unified OAM mechanism: OAM mechanism could be implemented across
AS by IGP and BGP extension of SID flooding. This is an easy-
to-implement the cross-AS OAM mechanism. If the control plane
is one or several centralized controller, the OAM policy can be
determined by the controller, and the related OAM policy can be
downloaded to the SR nodes seamlessly
(4) Traffic engineering: Traffic Engineering has been widely
addressed by using the IGP protocol extensions (for resources
Khasnabish, et al. Expires May 14, 2015 [Page 5]
Internet-Draft SR IP RAN use case November 2014
information propagation) and RSVP-TE for signaling explicit
paths. Different contexts and modes have been defined (single
vs. multiple domains, with or without bandwidth admission
control, centralized vs. distributed path computation, etc),
segment routing can help to implement traffic engineering in IP
RAN network.
(5) FRR: FRR technologies have been deployed by network operators in
order to cope with link or node failures through pre-computation
of backup paths. Segment routing can use the IP FRR technology
to simplify MPLS-TE
FRR([I-D.francois-spring-resiliency-use-case]).
(6) Flexible policy deployment: A key goal for SR is to steer a
packet to follow a specific path through the network. It is
possible to control the service performed at each SR node that
is forwarding the packets. Forwarding is one such service
provided by an SR node. The service policy can be applied to
the packets in each SR node.
(7) Simplification of management and operations: The complex RSVP-TE
and LDP signaling protocol are not required in the IP RAN
network anymore. Therefore, the configuration and operation
management become much simple than tradition RSVP-TE based IP
RAN network.
(8) Centralization controller or distribution protocol: the control
plane in IP RAN network can be IGP/BGP distribution protocol or
centralization controller.
(9) Zero-configuration for CSGs and ASGs: The CSGs and ASGs could do
little or zero-configuration by SID allocation mechanism
([I-D.lw-spring-sid-allocation]). One of the ASGs in the IP RAN
domain is selected as SRMN (segment routing management node),
which advertise the SID mapping information for the various
prefix associated with the SR nodes in the SR domain, and all
the other ASGs and CSGs could get the SID automatically from the
SRMN. There are zero-configuration for the CSGs and ASGs.
5. Unified Service Deployment
The centralization controller is supported in problem statement draft
([I-D.previdi-spring-problem-statement]) this section describe how
centralization controller is applied to the IP RAN network for
unified service deployment.
Khasnabish, et al. Expires May 14, 2015 [Page 6]
Internet-Draft SR IP RAN use case November 2014
+----------+ +----------+
| App | |Network |
| | |Management|
+----+-----+ +----------+
| |
| |
+---+------+ |
|Controller|----------------+
+----------+ |
........./....|....|...|.\........ |
. / | | | \ +------+
. / | | | \ .
+------+ . +----+ +----+ | | +----+ . +----+
| BS |-----.--|CSG1| |ASG1| |- -|--|RSG1|-.----|RNC1|
+------+ . +-+--+ +----+ | | +----+ . +----+
. | | | .
. | / \ .
+------+ . +-+--+ +----+ +----+ . +----+
| BS |-----.-|CSG2| |ASG2|--------|RSG2|--.---|RNC2|
+------+ . +----+ +----+ +----+ . +----+
. MPLS Stacked forwarding .
..................................
Figure 2: Centralization of Controller
Figure 2 shows an architecture for centralization of controller. The
control plane is separated from the forwarding plane. IP RAN
Controller is a software system that can be deployed either in a
network device or a separate computer server. IP RAN controllers
control 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. IP RAN controllers manage the IP RAN network based on
the network topology, actual states and status, which are operated by
the network administrator. The controller provide the northbound
interface to network management system used for service deployment,
monitoring, troubleshooting, fault location, etc.
CSG, ASG and RSG (we call them forwarding nodes) are only responsible
for MPLS stack forwarding. RSVP-TE and LDP signaling protocol are
not required in these forwarding nodes. They only need to support
topology collecting and report them to controller. Forwarding nodes
keep the basic routing functions in order to establish control and
management channel between IP RAN Controller/NMG and all the
forwarding nodes accepts network resources and states from the
controller.
Khasnabish, et al. Expires May 14, 2015 [Page 7]
Internet-Draft SR IP RAN use case November 2014
5.1. Requirement for Control Node
The logical centralization controller is introduced in the IP RAN
network. Centralization controller is responsible for network
topology collecting and label distribution based on the service.
Requirement for control node:
(1) Control node should support collecting network topology, and
managing network resource, route computing, and MPLS label
distribution.
(2) Control node support service chaining.
(3) Control node support secure channel, and it should establish the
secure connection between forwarding node.
5.2. Requirement for Forwarding Node
5.2.1. Forwarding Node Structure
The forwarding node structure in segment routing based IP RAN network
is as following:
+-----------------------------------------+
| |
| +---------+ +--------+ |
| | Control | | Config | |
| | Agent | | | |
| +---------+ +--------+ |
| |
| +-----------+ +----------------+ |
| | Routing | |Topo management | |
| +-----------+ +----------------+ |
| |
| +---------+ +----------+ |
| | TEDB | |policy DB | |
| +---------+ +----------+ |
+-----------------------------------------+
Figure 3: Forwarding node structure
The forwarding node simplifies the signaling related components, such
as signal protocol component, signal label database, and a new
component Control Agent is introduced to communicate with the
centralization Controller.
Khasnabish, et al. Expires May 14, 2015 [Page 8]
Internet-Draft SR IP RAN use case November 2014
Control Agent: control agent is used to communicate with the
centralization controller. The forwarding node reports its topology
and resource information, and receives the label distributed and
policy through control agent. The control agent establishes the
secure channel with controller. The BGP-LS protocol is recommended
to use as the communication protocol between control agent and
controller in this document.
Config: the config component is used for management and
configuration. It is the interface with network management.
Routing: is the traditional component, is used for route computing.
The routing protocol (ISIS, OSPF, and BGP) is required for the
forwarding node.
Topo management: Topology management is responsible for topology
computing, and topology status reporting.
TEDB: The label database.
Policy DB: policy database.
6. Security Considerations
TBD.
7. Acknowledgements
In progress.
8. IANA Considerations
This is no IANA request for this document.
9. Normative References
[I-D.filsfils-rtgwg-segment-routing]
Filsfils, C., Previdi, S., Bashandy, A., Decraene, B.,
Litkowski, S., Horneffer, M., Milojevic, I., Shakir, R.,
Ytti, S., Henderickx, W., Tantsura, J., and E. Crabbe,
"Segment Routing Architecture", draft-filsfils-rtgwg-
segment-routing-01 (work in progress), October 2013.
[I-D.francois-spring-resiliency-use-case]
Francois, P., Filsfils, C., Decraene, B., and R. Shakir,
"Use-cases for Resiliency in SPRING", draft-francois-
spring-resiliency-use-case-02 (work in progress), April
2014.
Khasnabish, et al. Expires May 14, 2015 [Page 9]
Internet-Draft SR IP RAN use case November 2014
[I-D.gredler-idr-bgp-ls-segment-routing-extension]
Gredler, H., Ray, S., Previdi, S., Filsfils, C., Chen, M.,
and J. Tantsura, "BGP Link-State extensions for Segment
Routing", draft-gredler-idr-bgp-ls-segment-routing-
extension-02 (work in progress), October 2014.
[I-D.ietf-mpls-seamless-mpls]
Leymann, N., Decraene, B., Filsfils, C., Konstantynowicz,
M., and D. Steinberg, "Seamless MPLS Architecture", draft-
ietf-mpls-seamless-mpls-07 (work in progress), June 2014.
[I-D.lw-spring-sid-allocation]
Liao, T., Bo, W., hu, f., and B. Khasnabish, "SPRING SID
Allocation", draft-lw-spring-sid-allocation-00 (work in
progress), October 2014.
[I-D.previdi-spring-problem-statement]
Previdi, S., Filsfils, C., Decraene, B., Litkowski, S.,
Horneffer, M., Geib, R., Shakir, R., and R. Raszuk,
"SPRING Problem Statement and Requirements", draft-
previdi-spring-problem-statement-04 (work in progress),
April 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Bhumip Khasnabish
ZTE TX Inc.
55 Madison Avenue, Suite 160
Morristown, New Jersey 07960
USA
Phone: +001-781-752-8003
Email: bhumip.khasnabish@ztetx.com, vumip1@gmail.com
Fangwei Hu
ZTE Corporation
No.889 Bibo Rd
Shanghai 201203
China
Phone: +86 21 68897637
Email: hu.fangwei@zte.com.cn
Khasnabish, et al. Expires May 14, 2015 [Page 10]
Internet-Draft SR IP RAN use case November 2014
Luis M. Contreras
Telefonica I+D
Ronda de la Comunicacion, s/n
Sur-3 building, 3rd floor
Madrid 28050
Spain
Email: luismiguel.contrerasmurillo@telefonica.com
URI: http://people.tid.es/LuisM.Contreras/
Khasnabish, et al. Expires May 14, 2015 [Page 11]
