One document matched: draft-zhang-i2rs-mbb-usecases-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd"[
<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3036 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3036.xml">
<!ENTITY RFC3746 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3746.xml">
<!ENTITY RFC4655 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4655.xml">
<!ENTITY RFC4760 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4760.xml">
<!ENTITY RFC5283 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5283.xml">
<!ENTITY RFC6718 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6718.xml">
<!ENTITY I-D.ietf-i2rs-problem-statement SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-problem-statement.xml">
<!ENTITY I-D.ietf-i2rs-architecture SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-architecture.xml">
<!ENTITY I-D.ietf-i2rs-rib-info-model SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-i2rs-rib-info-model.xml">
<!ENTITY I-D.ietf-mpls-ldp-multi-topology SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-ldp-multi-topology">
<!ENTITY I-D.ietf-mpls-seamless-mpls SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-seamless-mpls">
<!ENTITY I-D.li-mpls-seamless-mpls-mbb SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.li-mpls-seamless-mpls-mbb">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-zhang-i2rs-mbb-usecases-01"
ipr="trust200902">
<front>
<title abbrev="Use Cases of I2RS in MBB">Use Cases of I2RS in Mobile
Backhaul Network</title>
<author fullname="Li Zhang" initials="L." surname="Zhang">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Huawei Bld., No.156 Beiqing Rd.</street>
<city>Beijing</city>
<code>100095</code>
<country>China</country>
</postal>
<email>monica.zhangli@huawei.com</email>
</address>
</author>
<author fullname="Zhenbin Li" initials="Z." surname="Li">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Huawei Bld., No.156 Beiqing Rd.</street>
<city>Beijing</city>
<code>100095</code>
<country>China</country>
</postal>
<email>lizhenbin@huawei.com</email>
</address>
</author>
<author fullname="Dapeng Liu" initials="D." surname="Liu">
<organization>China Mobile</organization>
<address>
<postal>
<street>Unit2, 28 Xuanwumenxi Ave,Xuanwu District</street>
<city>Beijing</city>
<code>100053</code>
<country>China</country>
</postal>
<email>liudapeng@chinamobile.com</email>
</address>
</author>
<author fullname="Susan Hares" initials="S" surname="Hares">
<organization>Hickory Hill Consulting</organization>
<address>
<postal>
<street>7453 Hickory Hill</street>
<city>Saline</city>
<region>MI</region>
<code>48176</code>
<country>USA</country>
</postal>
<email>shares@ndzh.com</email>
</address>
</author>
<date month="February" year="2014"/>
<abstract>
<t>In a mobile backhaul network, traditional configuration and diagnoses
mechanisms based on device-level management tools and manual processing
are ill-suited to meet the requirements of today's scalable, flexible,
and complex network. Thanks to the new innovation of Interface to the
Routing System's (I2RS) programmatic interfaces, as defined in <xref
target="I-D.ietf-i2rs-architecture"/>, an alternative way is available
to control the configuration and diagnose the operational results.
This document discusses the use case for I2RS in mobile backhaul
network.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>In mobile backhaul network, traditional configuration and diagnoses
mechanisms based on device-level management tools and manual processing
are ill-suited to meet the requirements of today's scalable, flexible,
and complex network. The mobile backhaul network now needs to serve
various radio access modes and applications across 2G/3G / LTE/5G, build
various network architectures based on the number of network devices or
the integration of different Areas or Autonomous System Numbers (ASNs),
and support various network protocols that can be adopted to meet different
network requirements. These needs make the mobile backhaul network
configuration more and more arduous.</t>
<t>Interface to the Routing System's (I2RS) Programmatic interfaces, as
defined in <xref target="I-D.ietf-i2rs-architecture"/>, provides an
alternative way to control the configuration and diagnose the operational
results. The use cases described in this document cover the critical
elements of mobile backhaul networks, such as: application configuration,
route policy enforcement, service tunnel implementation, protection
mechanisms and network monitoring. The goal is to increase the community's
understanding of the mobile backhaul requirements for I2RS in a
the context of an entire network solution.</t>
</section>
<section title="Definitions">
<t>I2RS: Interface to the Routing System</t>
<t>IGP: Interior Gateway Protocol</t>
<t>BGP: Border Gateway Protocol</t>
<t>MPLS: Multi-Protocol Label Switching</t>
<t>LDP: Label Distribution Protocol</t>
<t>RSVP-TE: Resource Reservation Protocol Traffic Engineering</t>
<t>PWE3: Pseudo Wire Emulation Edge-to-Edge</t>
<t>VPN: Virtual Private Network</t>
<t>L2VPN: L2 Virtual Private Network</t>
<t>L3VPN: L3 Virtual Private Network</t>
<t>SS-PW: Singe Segment PW</t>
<t>MS-PW: Multi-Segment PW</t>
<t>HVPN: Hierarchical VPN</t>
<t>EPC: Pseudo Wire Emulation Edge-to-Edge</t>
<t>LTE: Long Term Evolution</t>
<t>FRR: Fast Reroute</t>
<t>ECMP: Equal Cost Multi-path</t>
</section>
<section title="Application Configuration">
<section title="Application Configuration">
<t>The mobile backhaul network has evolved into an IP-based network,
which faces three main challenges in network construction: </t>
<t><list style="numbers">
<t>various radio access modes: <list style="empty">
<t>To protect existing investment and end user resource,
TDM/ATM-based access modes belonging to 2G and 3G will coexist
with Ethernet-based access mode belonging to 3G, LTE, and 5G for
an extended time into the future. The radio architecture evolution will
bring out new radio interfaces, such as the X2 interface in LTE
which will not work in hub-spoke communication mode
and needs much more shorter latency. A mobile backhaul
network must be built to have the ability to adapt to all
the mobile access modes, providing PWE3 service for TDM
/ATM-based access mode and Native IP/Ethernet, PWE3/VPLS or
L3VPN service for IP-based access mode.</t>
</list></t>
<t>various radio applications: <list style="empty">
<t>A variety of radio applications (such as OM, signaling,
data, video, etc. ) which have different quality of services
(QoS), should be delivered in specific service channels in
mobile backhaul networks, meaning there will be more than
one PW or L3VPN instances binding with specific interfaces and
service tunnels.</t>
</list></t>
<t>various network architectures:<list style="empty">
<t>The mobile backhaul network maybe consist of hundreds of
nodes in a small county or thousands of nodes in a populous
region. It will be an integration of different ASNs rather
than a single AS, when EPC is deployed in the Core network
with LTE. The network devices on different points of the
network (e.g. access\aggregation\core) have different routing
and protocol processing capabilities, resulting in an
integration of different IGP routing areas rather than a
single large IGP routing area. Within various network
architectures, different service modes should be provided,
such as SS- PW or MS-PW, E2E L3VPN or HVPN, Seamless MPLS, and
the integration of them.</t>
</list></t>
</list></t>
</section>
<section title="Requirements for I2RS">
<t>The challenges in mobile backhaul network construction show the
flexibility and complexity requirements of network configuration and
modification, such as:
<list style="symbols">
<t> where the T-LDP should be configured, </t>
<t> where a BGP peer should be established, </t>
<t> where the VPN instance should be deployed, and </t>
<t> where the BGP-based LSP should be set up. </t>
</list></t>
<t> Faced with flat or reduced budgets, network operators are trying to squeeze the most
from their network using device-level management tools and manual
processing. In contrast to management of entire network devices, I2RS'
programmatic interface would allow network operators to distribute
such configurations from a central location where global mobile
backhaul network solution provisioning information could be stored
Use of I2RS clients to distribute time-critical changes
in configuration to I2RS agents associated with each node would
simplify and automate configuration and monitoring of a mobile backhaul network
to allow it to readily adapt to changing network sizes (and scales) and radio
applications.</t>
<t> I2RS Clients-Agent communication needs to pass information on:
<list style="symbols">
<t> T-LDP configurations and status; </t>
<t> BGP peer configurations, peer topologies and status;</t>
<t> BGP-based LSP topologies and status; </t>
<t> Reset VPN topologies, and per node configurations; </t>
</list></t>
<t> While a beginning exists in the I2RS RIB Information Model
[<xref target="I-D.ietf-i2rs-rib-info-model" />] which includes
in the route interfaces with MPLS LSP ro VPN technology,
additional features need to be added to support mobile
backhaul networks. </t>
</section>
</section>
<section title="Route Policy Enforcement">
<section title="Route Policy Description">
<t>The route policy in mobile backhaul networks mainly refers to BGP
policy when L3VPN is used to serve the radio applications. The
complexity of today's network architecture and radio interfaces make
it very difficult to apply a network-wide route policy, for:</t>
<t><list style="symbols">
<t>avoiding route advertisement across entire network<list
style="empty">
<t>When a mobile backhaul network contains more than 500
nodes, utilizing a multi-segments service like HVPN is
recommended to reduce the routing and protocol processing
overhead of network devices. BGP policy should be configured
with prefix filters to advertise only the default or aggregate
route to the access nodes which have limited capability, while
advertising to the whole network routes to the core nodes which
must have capability to store large number of routes.</t>
</list></t>
<t>supporting best route selection for VPN FRR or ECMP<list
style="empty">
<t>The mobile backhaul network is recommended to be built with
a multi-homed network architecture for node failure
protection, where VPN FRR or ECMP should be configured. The
best route selection relies on BGP Policy using Local
Preference, MED or other path attributes defined in <xref
target="RFC4760"/>. When a BGP RR is adopted to simplify the BGP
peer architecture from full-mesh mode, the policy would become
more complex, in some cases may make be per-peer or per-route
worse.</t>
</list></t>
<t>allowing On-demand route advertisement<list style="empty">
<t>The advent of X2 interfaces in LTE, which need specific
route information between any two access nodes, makes the
network route advertisement more dynamic and
unpredictable. The BGP policy should be adjusted dynamically
to meet this route advertisement need across the entire
network.</t>
</list></t>
</list></t>
</section>
<section title="Requirements for I2RS">
<t>Route policy enforcement in mobile backhaul networks needs to be much
more dynamic and flexible. The I2RS interface provides a programmatic
way to configure (both policy and device) and monitor thousands of devices
individually whose configuration is based on the devices role (such as ASRSs in one AS,
ASBRs between ASs and other service-touch nodes). Current methods
take hours (or even days) to configure route policy across a network.</t>
<t>In contrast, I2RS clients could contact I2RS agents on nodes to
query role-based information from the network status. After
collecting the status, the I2RS client could develop the BGP policies
based on role information and push the BGP policies to the I2RS agents
that would load the alternate policies into the network device.
The I2RS Agents loading the alternate policies could then send status
back to the I2RS Client. </t>
</section>
</section>
<section title="Service Tunnel Implementation">
<section title="Service Tunnel Description">
<t>In mobile backhaul network, more than one kind of Service Tunnel
can be used according to network ability or other consideration in
different scenarios. The Tunnel deployment use case in mobile backhaul
includes:</t>
<t><list style="symbols">
<t>MPLS LDP LSP<list style="empty">
<t>MPLS LDP LSP is set up through LDP protocol. Both Label
Advertisement Mode of Downstream Unsolicited (DU) and
Downstream on Demand (DOD) defined in <xref target="RFC3036"/>
can be used individually or integrated across access networks
and aggregate/core networks. If needed, the longest length match
defined in <xref target="RFC5283"/> for LDP LSP should be
supported. MPLS LDP LSP has excellent scalability with flexible
policy to control the label advertisement of route, especially
in DU mode, to decrease needless LSPs to
reduce the LSP capability requirement of network devices.</t>
</list></t>
<t>MPLS-TE LSP<list style="empty">
<t>MPLS-TE LSP is set up through RSVP-TE protocol, which has
multiple path control attributes (such as explicit-path, path
affinity property , path bandwidth assurance , path hop
limitation, e.g.) and multiple protection modes (such as
hot-standby, Fast Re-Route, protection group, e.g.). MPLS-TE
LSP should be designed using the attributes and protection
modes according to the requirements of the service delivery
as integrated across access network and
aggregate/cores network.</t>
</list></t>
<t>MPLS-TP LSP<list style="empty">
<t>MPLS-TP includes unidirectional LSP, bidirectional
co-routed LSP, and bidirectional associated LSP, which can be
calculated and set up manually or using dynamic network
protocols such as GMPLS. In mobile backhaul networks, the LSP
selection depends on the service need, and the creation of
MPLS-TP LSP is always assumed to be decoupled with the protocol
control plane running on separate network devices. Ideally, the
static MPLS-TP LSP should be designed and configured
on the centralized control plane.</t>
</list></t>
</list></t>
</section>
<section title="Requirements for I2RS">
<t>The mobile backhaul network is divided into an access network and
an aggregation/core network where service tunnel implementation is not
constant and unique. Therefore, it may be necessary to deploy
different kind of LSPs separately (such as LDP LSP or MPLS-TE LSP
in both access network and aggregate/core networks) or simultaneously
(such as MPLS-TP static LSP in access network while LDP LSP or
MPLS-TE LSP in aggregate/core network). Network
operators need to know the ability of all of the network
devices and the service requirements to make the most appropriate
tunnel implementation.</t>
<t> I2RS clients can provide centralized control of many
network devices via the I2RS Client-Agent communication.
The I2RS programmatic interface can automate the
collection and analysis of each device's capability so that
the centralized I2RS client could calculate the
optimal LSP path and distribute the configuration to individual devices.
While the I2RS RIB Information Model [<xref target="I-D.ietf-i2rs-rib-info-model" />]
provides for routes with tunnels or MPLS LSP, the features defined
in this model are not sufficient to configure both types
of LSPs needed for the VPN technology in mobile
backhaul networks. Additional I2RS Informational models
need to be created to support these features.
</t>
</section>
</section>
<section title="Protection Mechanism">
<section title="Protection Mechanism Description">
<t>The SLA for radio services is strict, which requires interworking among
multiple protection mechanisms. Two critical aspects should be taken
into account for inter-working, hierarchical protection architectures
and multiple OAM protocol interactions.</t>
<t><list style="numbers">
<t>tunnel protection:<list style="empty">
<t>The protection mechanisms of different the tunnel protocols,
mentioned above, are different from each other. To enhance the
reliability, LDP LSP should configure LDP FRR, which is
calculated depending on the protect route algorithm, and
be Loop-Free Algorithm (LFA), Remote-LFA, or Maximally
Redundant Trees (MRT) used together with LDP MT as described in
<xref target="I-D.ietf-mpls-ldp-multi-topology"/>. MPLS-TE LSP
should apply TE Fast Reroute or TE hot-standby. When MPLS-TP
LSP is used, the LSP protection group should be configured
with 1:1 or 1+1 mode for MPLS-TP line protection, as well as
wrapping or steering modes fault processing for MPLS-TP ring
protection.</t>
</list></t>
<t>service protection: <list style="empty">
<t>Service protection is recommended to be configured for node
failure handover in mobile backhaul network, where PW
redundancy defined in <xref target="RFC6718"/> or BGP VPN FRR
or ECMP realization should be deployed exactly.</t>
</list></t>
</list></t>
</section>
<section title="Requirements for I2RS">
<t>The hierarchical protection architecture in mobile backhaul network
offer high network reliability and more flexibility to meet the
various needs of the tunnels and services. The I2RS interface in this use
case is needed to automate the configuration and monitoring
so that tunnel protection and service protection interwork in a
flexible and reliable manner.</t>
</section>
</section>
<section title="Network Monitoring">
<section title="Network Monitoring Description">
<t>The mobile backhaul network operators are asked to give an accurate
cause when a link or node failure occurs, and get the real
reason for service quality reduction. They need to apply different
network monitor tools for different service mode, like Network Quality
Analysis (NQA), MPLS-TP OAM, and IP Flow Performance Monitor (IPFPM).
Determining the exact traffic path is really significant
when using IPFPM for point-to-point detection.</t>
<t>Multiple monitor tools require network operators to distinguish
granular traffic flow to apply the appropriate one. At the same time,
getting the traffic path with traditional device-level management tools
is difficult, which may enhancing the existing protocols or designing
a new specific protocol to do the job. Both will increase the burden
of mobile backhaul network.</t>
</section>
<section title="Requirements for I2RS">
<t>The I2RS architecture (client-agent) should solve the two problems
mentioned above naturally by enabling the use of centralized controllers,
which control and manage the entire network's devices and store the whole
routing and service information directly. Meanwhile, the outages and traffic congestion
or discards can be detected real-time with I2RS
Client(s) connected to the I2RS agents in each node which provide
real-time status via notification service. An I2RS client with this ability
will allow the I2RS clients to keep optimal state dynamically all the time.</t>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>The mobile backhaul network use cases described in this document
assumes use of I2RS’s programmatic interfaces described in the
I2RS framework mentioned in<xref target="I-D.ietf-i2rs-architecture"/>.
This document does not change the underlying security issues inherent in
the existing <xref target="I-D.ietf-i2rs-architecture"/>.</t>
</section>
</middle>
<back>
<references title="Normative References">
&RFC2119;
</references>
<references title="Informative Reference">
&RFC3036;
&RFC4760;
&RFC5283;
&RFC6718;
&I-D.ietf-mpls-seamless-mpls;
&I-D.li-mpls-seamless-mpls-mbb;
&I-D.ietf-mpls-ldp-multi-topology;
&I-D.ietf-i2rs-problem-statement;
&I-D.ietf-i2rs-architecture;
&I-D.ietf-i2rs-rib-info-model;
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 19:47:46 |