SPRING WG B. Khasnabish
Internet-Draft ZTE TX Inc.
Intended status: Informational F. Hu
Expires: September 28, 2014 ZTE Corporation
March 27, 2014
Segment Routing in IP RAN use case
draft-kh-spring-ip-ran-use-case-00.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 September 28, 2014.
Copyright Notice
Copyright (c) 2014 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
Khasnabish & Hu Expires September 28, 2014 [Page 1]
Internet-Draft SR IP RAN use case March 2014
(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
6. Security Considerations . . . . . . . . . . . . . . . . . . . 8
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 8
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8
9. Normative References . . . . . . . . . . . . . . . . . . . . 8
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9
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
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
Khasnabish & Hu Expires September 28, 2014 [Page 2]
Internet-Draft SR IP RAN use case March 2014
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 & Hu Expires September 28, 2014 [Page 3]
Internet-Draft SR IP RAN use case March 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 & Hu Expires September 28, 2014 [Page 4]
Internet-Draft SR IP RAN use case March 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.
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
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.
Khasnabish & Hu Expires September 28, 2014 [Page 5]
Internet-Draft SR IP RAN use case March 2014
(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.
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 & Hu Expires September 28, 2014 [Page 6]
Internet-Draft SR IP RAN use case March 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 forwarding node accepts network resources and states
from the controller.
Khasnabish & Hu Expires September 28, 2014 [Page 7]
Internet-Draft SR IP RAN use case March 2014
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 Segment Routing", draft-
francois-spring-resiliency-use-case-00 (work in progress),
January 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-01 (work in progress), February 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-06 (work in progress), February
2014.
[I-D.previdi-spring-problem-statement]
Previdi, S., Filsfils, C., Decraene, B., Litkowski, S.,
Horneffer, M., and R. Geib, "SPRING Problem Statement and
Requirements", draft-previdi-spring-problem-statement-00
(work in progress), February 2014.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
Khasnabish & Hu Expires September 28, 2014 [Page 8]
Internet-Draft SR IP RAN use case March 2014
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 68896273
Email: hu.fangwei@zte.com.cn
Khasnabish & Hu Expires September 28, 2014 [Page 9]