Internet DRAFT - draft-li-ospf-auto-mbb-te-path
draft-li-ospf-auto-mbb-te-path
Network Working Group Z. Li
Internet-Draft L. Zhang
Intended status: Experimental Y. Liu
Expires: August 22, 2013 Huawei Technologies
February 18, 2013
OSPF Extensions for Automatic Computation of MPLS Traffic Engineering
Path Using Traffic Engineering Layers and Areas
draft-li-ospf-auto-mbb-te-path-00
Abstract
As the network scale expands, especially in the mobile backhaul
network, automatic computation of MPLS Traffic Engineering (TE) path
becomes very important. But owing to requirements on the MPLS TE
path, explicit path or affinity property has to be introduced for the
path computation. This causes the complexity of MPLS TE path design.
The document proposes an architecture and corresponding OSPF
extensions to improve automation on computation of MPLS TE path.
MPLS TE networks are divided into different traffic engineering
layers and areas according to the characteristics of the network
topology. MPLS TE path can compute automatically based on traffic
engineering layers and areas to satisfy major requirements to bear
mobile network services.
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 August 22, 2013.
Li, et al. Expires August 22, 2013 [Page 1]
Internet-Draft OSPF for Auto TE Path Using TLs and TAs February 2013
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
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Mobile Backhaul Network and Service Deployment . . . . . . 3
2.2. Weakness of Existing MPLS TE Path Computation . . . . . . 4
3. Architecture of MPLS TE Auto Path Computation . . . . . . . . 6
3.1. Concept of TL and TA . . . . . . . . . . . . . . . . . . . 6
3.2. TL and TA Information Flooding . . . . . . . . . . . . . . 8
3.3. Enhanced CSPF Algorithm Based on TL and TA . . . . . . . . 8
3.3.1. An Example of Enhanced CSPF Algorithm Based on TL
and TA . . . . . . . . . . . . . . . . . . . . . . . . 9
4. OSPF Extensions . . . . . . . . . . . . . . . . . . . . . . . 10
4.1. OSPF TA TLV and TL TLV Format . . . . . . . . . . . . . . 10
4.2. Elements of Procedure . . . . . . . . . . . . . . . . . . 11
4.3. Backward Compatibility . . . . . . . . . . . . . . . . . . 12
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. Normative References . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Li, et al. Expires August 22, 2013 [Page 2]
Internet-Draft OSPF for Auto TE Path Using TLs and TAs February 2013
1. Introduction
As the network scale expands, especially in the mobile backhaul
network, automatic computation of MPLS TE path becomes very
important. Since the mobile traffic has high SLA (Service Level
Agreement) requirement, MPLS TE is introduced to provide bandwidth
guarantee and traffic protection. On the other hand, in order to
provide traffic engineering properties, constraints such as explicit
path or affinity property has to be specified for a MPLS TE tunnel.
This causes that the path design is very complex. For example, when
explicit path is specified for a MPLS TE tunnel in a large scale
network, many hops along the MPLS TE path have to be specified. This
operation is cumbersome and error-prone. In addition, if new nodes
are introduced in the network, a lot of configuration of existing
explicit paths has to be changed.
This document proposes an architecture and corresponding OSPF
extensions to improve automation on computation of MPLS TE path.
MPLS TE layers and areas are introduced according to the
characteristics of the network topology. MPLS TE path can compute
more automatically based on MPLS TE layers and areas to reduce the
operation expense greatly.
2. Problem Statement
2.1. Mobile Backhaul Network and Service Deployment
Mobile multimedia devices such as smartphones are ubiquitous now
which runs a wide variety of bandwidth-intensive applications and
causes unprecedented growth in mobile data traffic. The huge growth
is challenging legacy network infrastructure. There are two obvious
solutions to cope with the growing bandwidth:
-- Increase the radio wireless interface bandwidth
-- Increase more cell sites: more LTE eNodeBs and associated Cell
Site Gateways(CSGs) are added in the networks. This causes the
network scale expands fast and has much effect on the service
provision.
Li, et al. Expires August 22, 2013 [Page 3]
Internet-Draft OSPF for Auto TE Path Using TLs and TAs February 2013
----------------
/ \
/ \
/ \
+----+ Access +----+
|CSG1| Ring 1 |ASG1|-------------
+----+ +----+ \
\ / \
\ / +----+
\ +----+ |RSG1|
-------------| | Aggregate +----+
|ASG2| Ring |
-------------| | +----+
/ +----+ |RSG2|
/ \ +----+
/ \ /
+----+ Access +----+ /
|CSG2| Ring 2 |ASG3|-------------
+----+ +----+
\ /
\ /
\ /
-----------------
Figure 1 Mobile Backhaul Network
The topology of mobile backhaul network is shown in the Figure 1. It
usually adopts ring topology to save fiber resource and it is divided
into the aggregate network and the access network. Cell Site
Gateways(CSGs) connects the eNodeBs and RNC site gateways(RSGs)
connects the RNCs. The mobile traffic is transported from CSGs to
RSGs. The network takes a typical aggregate traffic model that more
than one access rings will attach to one pair of aggregate site
gateways(ASGs) and more than one aggregate rings will attach to one
pair of RSGs.
2.2. Weakness of Existing MPLS TE Path Computation
Since the mobile traffic has high SLA (Service Level Agreement)
requirement, MPLS TE is introduced to provide bandwidth guarantee and
traffic protection. As the network scale expands, automation becomes
more and more important to reduce the effort of service provision.
But the path design becomes complex inevitably owing to guarantee
traffic engineering properties. There are following two primary
requirements for MPLS TE path computation:
1. Completely disjointed primary and backup LSP
Li, et al. Expires August 22, 2013 [Page 4]
Internet-Draft OSPF for Auto TE Path Using TLs and TAs February 2013
MPLS TE Hot-standby feature is introduced to implement traffic
protection. That is, primary LSP and backup LSP are setup at the
same time for one MPLS TE tunnel. In order to achieve higher
protection, it is requires that the primary and backup LSP should not
share any nodes and links. Thus when failure happens in the primary
path, the backup LSP can always take over the traffic.
According to current SPF(Shortest Path First) algorithm, if there is
no other constraints, it may be difficult to satisfy above path
computation requirement. For example, in figure 1 the primary path
computed from CSG1 to RSG1 may be CSG1->ASG2->ASG1->RSG1. Since the
primary path passes through both ASG2 and ASG1, the backup path
cannot be disjointed completely from the primary path. In fact, it
is apparent that the two completely disjointed paths exists from CSG1
to RSG1 in the figure 1.
2. Avoid passing through different access rings
When the mobile traffic is transported from the CSG to the RSG, it is
expected that the path would not pass through multiple access rings.
Since the bandwidth of the access ring is always designed to satisfy
requirement of its own, if mobile traffic from other access ring pass
through, the access ring is prone to be overloaded which will cause
traffic loss owing to traffic congestion.
When automatic path computation is done for MPLS TE tunnels, it may
be inevitable that the path will path through multiple access rings.
For example, in figure 1 the primary path computed from CSG1 to RSG2
may be CSG1->ASG2->CSG2->ASG3->RSG2 instead of
CSG1->ASG2->ASG3->RSG2.
There are two possible solutions to satisfy requirements described
above:
The first one is to set reasonable link cost. For example, the cost
of the key link between ASG1 and ASG2 can be set as a large value,
then the primary LSP will not be calculated to pass through the key
link and the backup LSP can be disjointed from the primary LSP
completely. The cost of the access ring can also be larger than the
aggregate ring to avoid that the traffic will pass through unexpected
rings.
The second one is to use explicit-path or affinity property to
achieve better path design. When explicit path is used, it has to
designate the exact nodes or links which the primary LSP and the
backup LSP go through. When affinity property is used, it can divide
different rings with different colors and the primary LSP and backup
LSP can setup with different affinity property.
Li, et al. Expires August 22, 2013 [Page 5]
Internet-Draft OSPF for Auto TE Path Using TLs and TAs February 2013
The two methods can satisfy the two requirements of path computation.
But as we know the mobile backhaul network faces more frequent
topology change than the fixed network. Adding and deleting of
eNodeB will change the access ring topology and which will change the
hops and cost for mobile traffic from the source to the destination.
It will be very complex and time-consuming to adjust the cost for a
large scale network or change explicit path or affinity property for
a great deal of MPLS TE tunnels. It is necessary to propose a more
automatic way to satisfy the requirements.
3. Architecture of MPLS TE Auto Path Computation
3.1. Concept of TL and TA
Li, et al. Expires August 22, 2013 [Page 6]
Internet-Draft OSPF for Auto TE Path Using TLs and TAs February 2013
10.10.10.10
+-----+ +-----+
|NodeD| |NodeE|
|L3A0 | |L3A0 |
+-----+--------+-----+
/// \\\
// \\
/ \
| |
| |
| Aggregate |
+---|--+ Ring 1 |
|NodeC | +--------+
|L2A0A3| | NodeB |
//+------+\ |L2A0A1A2|
/ \\ //+--------+ \
| +-----------+ / \ \\\
| | Node A |/ \ \\\\
|Access Ring 3|L2A0A1A2A3 | \ \\
| +-----------+ | ||
| | | | Access Ring 2 +-------+
\ / | | | |NodeH |
\\ // | | | |L1A2 |
+-----+ | | | +-------+
|NodeI| +-------+ \ | /
|L1A3 | |NodeG | \ | /
+-----+ |L1A1 | ---------------
+-------+ Acess Ring 1/
\ /
\ /
+-------+
| NodeF |
| L1A1 |
+-------+
1.1.1.1
Figure 2 Definition of TAs and TLs
New network constraints are introduced to improve automation of MPLS
TE path computation, As the figure above shows, the mobile backhaul
network can be divided into multiple layers and multiple areas. The
layers and areas can be designated easily according to the natural
physical topology. We propose two concepts below:
o TE Layer (TL): It indicates the physical layer of the node in the
network. The TL value should be increased from the access ring to
the aggregate ring layer by layer. The TL values from the access
ring to the aggregate ring can be not continuous. They just
Li, et al. Expires August 22, 2013 [Page 7]
Internet-Draft OSPF for Auto TE Path Using TLs and TAs February 2013
reflect the relation of the different layers. In order to
accommodate future network expansion, it is better that the lowest
TL value should not start from the 0 or 1.
o TE Area(TA): It indicates the physical ring of the node. All
nodes of the physical ring forms a natural area. TA value must be
unique in the whole network. TA is designed mostly according to
the physical topology with the aim to separate the obvious
physical areas. One node can have multiple TA values when it
belongs to multiple rings.
TL and TA are defined for every node instead of every link to reduce
the effort of configuration and operation. TA and TL indicates the
network layer and area which one node belongs to. TL and TA value
should be set for the node before the path of the TE LSP is
calculated just like that the cost of the link should be set before
the routes are calculated. TL and TA are only defined for MPLS TE
path computation according to the natural topology of the mobile
network. They have no relationship with IGP area or level.
3.2. TL and TA Information Flooding
After the TL and TA value are set for the node, the TL and TA
information of this node should be flooded through IGP. When all
nodes TL and TA information are flooded, every node in this route
region will have the whole TL and TA information which will be added
to the TEDB for TE LSP calculation. When a TE LSP requires path
computation in a source node , a new enhanced CSPF algorithm based on
TL and TA will be used to calculate the optimal path automatically.
3.3. Enhanced CSPF Algorithm Based on TL and TA
The enhanced CSPF algorithm based on TL and TA can calculate the TE
path more automatically comparing with the existing CSPF algorithm.
In order to achieve more automatic path computation, some new rules
are introduced for the CSPF algorithm.
We assume that:
o The high layer is TL high(TLh), the low layer is TL low(TLl);
o The source node of the LSP has the TA value TAs, the destination
node of LSP has the TA value TAd, the passed node has the TA value
TAp.
The rules for the enhanced CSPF algorithm are as follows:
Li, et al. Expires August 22, 2013 [Page 8]
Internet-Draft OSPF for Auto TE Path Using TLs and TAs February 2013
o Rule 1: If the destination node of the LSP is not in the same TA
as the source node or the passed node, the node in the different
layer will be the potential next-hop for the LSP path calculation.
o Rule 2: One LSP's TL track can not include TLh->TLl->TLh, this
means that the LSP cannot pass through the low layer twice.
o Rule 3: If the LSP reach a node that in the same TA as the
destination node, the LSP must be calculated in this TA only.
o Rule 4: If the LSP reach a node that among more than one TAs, the
node in different TA should be prior to be the next hop. This
rule ensures that the primary and backup LSPs would not pass the
same links.
Since these rules are applied to calculate both the primary and
secondary path automatically, rules for determining which is the
primary or the secondary should also be introduced. The rules are as
follows:
o Rule 5: The LSP which passes fewer TLs will be the primary LSP.
o Rule 6: If the two LSPs passes the same TLs, the one with shorter
metric in every layer from high to low will be the main LSP
3.3.1. An Example of Enhanced CSPF Algorithm Based on TL and TA
As the figure above shows, the TL and TA values are designed for
every node and the flooding has completed. Now the primary LSP and
the backup LSPp should setup from the source node(1.1.1.1) to the
destination node(10.10.10.10), the path calculation is as follows:
1. The source node(1.1.1.1) is TL1TA1 and the destination
node(10.10.10.10) is TL3TA0. The LSP path should be calculated
towards the node with higher TL value in TA1, according to Rule 1
. The candidate nodes are NodeA and NodeB and we assume that the
algorithm will choose NodeB as the next hop according to the
cost.
2. After get NodeB, there are three candidate nodes for the next hop
which are NodeA and NodeE and NodeH. Node H will be excluded
according to Rule 2, because it will cause the LSP to passe
through TL2->TL1->TL2, that means the LSP will pass another
access ring which is on the same low layer as the source node.
3. NodeB is in TA0, which is the same as the destination node, so we
can only choose NodeA or Node E, according to Rule 3
Li, et al. Expires August 22, 2013 [Page 9]
Internet-Draft OSPF for Auto TE Path Using TLs and TAs February 2013
4. TA1 has been passed, so the NodeB in TA1 is exclued according to
rule4
5. Node E is the best appropriate choice according to the Rules.As a
result ,we can get a path NodeF->NodeB->NodeE->NodeD
6. The other path is calculated according to the rules with the
nodes and links passed by the first path excluded. So we can get
the other path NodeF->NodeA->NodeC->NodeD.
7. Then we will select the primary path from these two paths.
According to the rule5 and rule6, the path
NodeF->NodeA->NodeC->NodeD is determined as the primary LSP and
the path NodeF->NodeB->NodeE->NodeD is the backup LSP.
4. OSPF Extensions
4.1. OSPF TA TLV and TL TLV Format
The OSPF TA TLV and TL TLV are used to advertise the TA and TL a node
belongs to. The OSPF TA TLV and TL TLV (advertised in an OSPF router
information LSA defined in [RFC4970]) has the following format:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
// Value //
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Where
Type: identifies the TLV type
Length: the length of the value field in octets
The format of the TA TLV and TL TLV are the same as the TLV format
used by the Traffic Engineering Extensions to OSPF (see [RFC3630]).
TLV:
OSPFv2 TA TYPE: TBD,
OSPFv2 TL TYPE: TBD,
OSPFv3 TA TYPE: TBD
OSPFv3 TL TYPE: TBD
Li, et al. Expires August 22, 2013 [Page 10]
Internet-Draft OSPF for Auto TE Path Using TLs and TAs February 2013
LENGTH: Variable
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE-Area number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE-Area number N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE-Layer number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1 - OSPF TE-Area Group TLV and TE-Layer Group TLV format
4.2. Elements of Procedure
The OSPF TA and TL TLV is carried within the OSPF Routing Information
LSA. Specifically, a router MUST originate a new LSA whenever the
content of this information changes, or whenever required by regular
routing procedure (e.g., updates). The OSPF TLVs are OPTIONAL and
MUST NOT included more than one instance. If either of the TLVs
occurs more than once within the OSPF Router Information LSA, only
the first instance is processed, subsequent TLV(s) SHOULD be silently
ignored.
When the TA or TL of a node change, a new router information LSA
SHOULD be advertised. The flood scope is OSPF Area using type 10 LSA
or Routing-domain scope using type 11 LSA.
As defined in [RFC2370] for OSPFv2 and in [RFC2740]for OSPFv3, the
flooding scope of the Router Information LSA is determined by the LSA
Opaque type for OSPFv2 and the values of the S1/S2 bits for OSPFv3.
The TA TLV and TL TLV may be advertised within an Area-local or
Routing-domain scope Router Information LSA, depending on the MPLS TE
profile:
- If the MPLS TE Area and Layer are contained within a single area,
the TA TLV and TL TLV MUST be generated within an Area-local Router
Information LSA.
- If the MPLS TE Area and Layer spans multiple OSPF areas, the TA TLV
and TL TLV MUST be generated within a Routing-domain scope router
Li, et al. Expires August 22, 2013 [Page 11]
Internet-Draft OSPF for Auto TE Path Using TLs and TAs February 2013
information LSA.
4.3. Backward Compatibility
The TLVs defined in this document do not introduce any
interoperability issue. For OSPF, a router not supporting the TLV
SHOULD just silently ignore the TLV as specified in [RFC2370].
5. IANA Considerations
The registry for the Router Information LSA is defined in [RFC4970].
IANA assigned a new OSPF TLV code-point for the OSPF-TE-Attributes
TLVs carried within the Router Information LSA.
Value Sub-TLV References
----- -------- ----------
TBD OSPF-TE-Area TLV (IPv4) RFC 4970
TBD OSPF-TE-Layer TLV (IPv4) RFC 4970
TBD OSPF-TE-Area TLV (IPv6) RFC 4970
TBD OSPF-TE-Layer TLV (IPv6) RFC 4970
6. Security Considerations
TBD.
7. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370,
July 1998.
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6",
RFC 2740, December 1999.
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering
(TE) Extensions to OSPF Version 2", RFC 3630,
September 2003.
[RFC4970] Lindem, A., Shen, N., Vasseur, JP., Aggarwal, R., and S.
Shaffer, "Extensions to OSPF for Advertising Optional
Router Capabilities", RFC 4970, July 2007.
Li, et al. Expires August 22, 2013 [Page 12]
Internet-Draft OSPF for Auto TE Path Using TLs and TAs February 2013
Authors' Addresses
Zhenbin Li
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: lizhenbin@huawei.com
Li Zhang
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: monica.zhangli@huawei.com
Yuanjiao Liu
Huawei Technologies
Huawei Bld., No.156 Beiqing Rd.
Beijing 100095
China
Email: liuyuanjiao@huawei.com
Li, et al. Expires August 22, 2013 [Page 13]
