Internet DRAFT - draft-li-ccamp-auto-mbb-te-path
draft-li-ccamp-auto-mbb-te-path
Network Working Group Z. Li
Internet-Draft L. Zhang
Intended status: Standards Track Y. Liu
Expires: March 28, 2014 Huawei Technologies
September 24, 2013
IGP Extensions for Automatic Computation of MPLS Traffic Engineering
Path Using Traffic Engineering Layers and Areas
draft-li-ccamp-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 and ISIS
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 March 28, 2014.
Li, et al. Expires March 28, 2014 [Page 1]
Internet-Draft OSPF for Auto TE Path Using TLs and TAs September 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 . . . . . . . . . . . . . . . . . . . . . . . . 2
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 . . . . . . . . . . . . . 7
3.3. Enhanced CSPF Algorithm Based on TL and TA . . . . . . . 7
3.3.1. An Example of Enhanced CSPF Algorithm Based on TL and
TA . . . . . . . . . . . . . . . . . . . . . . . . . 8
4. IGP Extensions . . . . . . . . . . . . . . . . . . . . . . . 9
4.1. OSPF Extensions . . . . . . . . . . . . . . . . . . . . . 10
4.1.1. OSPF TA TLV and TL TLV Format . . . . . . . . . . . . 10
4.1.2. Elements of Procedure . . . . . . . . . . . . . . . . 11
4.1.3. Backward Compatibility . . . . . . . . . . . . . . . 12
4.2. IS-IS Extensions . . . . . . . . . . . . . . . . . . . . 12
4.2.1. IS-IS TA TLV and TL TLV Format . . . . . . . . . . . 12
4.2.2. Elements of Procedure . . . . . . . . . . . . . . . . 13
4.2.3. Backward Compatibility . . . . . . . . . . . . . . . 13
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
5.1. OSPF . . . . . . . . . . . . . . . . . . . . . . . . . . 13
5.2. IS-IS . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6. Security Considerations . . . . . . . . . . . . . . . . . . . 14
7. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
7.1. Normative References . . . . . . . . . . . . . . . . . . 14
7.2. Informative Reference . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction
Li, et al. Expires March 28, 2014 [Page 2]
Internet-Draft OSPF for Auto TE Path Using TLs and TAs September 2013
As the network scale expands, especially in the mobile backhaul
network, automatic computation of MPLS TE path becomes very important
([I-D.li-mpls-seamless-mpls-mbb]). 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 and
ISIS 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.
----------------
/ \
/ \
/ \
+------+ +----+ Access +----+
|eNodeB|---|CSG1| Ring 1 |ASG1|-------------
+------+ +----+ +----+ \
\ / \
\ / +----+ +---+
\ +----+ |RSG1|----|RNC|
Li, et al. Expires March 28, 2014 [Page 3]
Internet-Draft OSPF for Auto TE Path Using TLs and TAs September 2013
-------------| | Aggregate +----+ +---+
|ASG2| Ring |
-------------| | +----+ +---+
/ +----+ |RSG2|----|RNC|
/ \ +----+ +---+
/ \ /
+------+ +----+ Access +----+ /
|eNodeB|---|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) connect the eNodeBs and RNC site gateways(RSGs)
connect 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
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 requires that the primary and backup LSP should not
share any nodes and links. Thus when a failure happens on 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
Li, et al. Expires March 28, 2014 [Page 4]
Internet-Draft OSPF for Auto TE Path Using TLs and TAs September 2013
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 March 28, 2014 [Page 5]
Internet-Draft OSPF for Auto TE Path Using TLs and TAs September 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
192.168.10.1
+-----+ +-----+
|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 |
+-------+
Li, et al. Expires March 28, 2014 [Page 6]
Internet-Draft OSPF for Auto TE Path Using TLs and TAs September 2013
192.168.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
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
Li, et al. Expires March 28, 2014 [Page 7]
Internet-Draft OSPF for Auto TE Path Using TLs and TAs September 2013
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:
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:
Li, et al. Expires March 28, 2014 [Page 8]
Internet-Draft OSPF for Auto TE Path Using TLs and TAs September 2013
1. The source node(192.168.1.1) is TL1TA1 and the destination
node(192.168.10.1) 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
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. IGP Extensions
We define an enhanced CSPF algorithms based on TE layers and TE areas
to satisfy the path calculation requirements described above. Before
the path calculation, TL and TA information of the node should be
flooded through IGPs. This document also specifies IGP (OSPF and IS-
IS) TE Area and TE Layer TLVs (Type Length Value) allowing for the
automatic discovery of the TE Area and TE Layer of a node, to be
carried in the OSPF Router Information (Link State Advertisement) LSA
[RFC4970] and IS-IS Router Capability TLV [RFC4971]. The routing
extensions specified in this document provide the ability to signal
multiple TE Area and TE Layer values.
There are relatively tight real-time constraints on the operation of
IGPs (such as OSPF and IS-IS). For this reason, some care needs to
be taken when extend to carry additional information in an IGP. The
information described in this document is relatively small in total
Li, et al. Expires March 28, 2014 [Page 9]
Internet-Draft OSPF for Auto TE Path Using TLs and TAs September 2013
volume (compared with other information already carried in IGPs), and
also relatively stable (i.e., changes are based on configuration
changes, but not on dynamic events within the network, or on dynamic
triggers such as the leaking of information from other routing
protocols or routing protocol instances).
4.1. OSPF Extensions
4.1.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 are 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
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Li, et al. Expires March 28, 2014 [Page 10]
Internet-Draft OSPF for Auto TE Path Using TLs and TAs September 2013
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE-Area number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
// //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE-Area number N |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TE-Layer number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3 OSPF TE-Area TLV and TE-Layer TLV format
4.1.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 and subsequent TLV(s) SHOULD be
silently ignored.
When the TA or TL of a node changes, 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 [RFC5250] for OSPFv2 and in [RFC5340]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
information LSA.
Li, et al. Expires March 28, 2014 [Page 11]
Internet-Draft OSPF for Auto TE Path Using TLs and TAs September 2013
4.1.3. Backward Compatibility
The OSPF TLVs defined in this document do not introduce any
interoperability issue. A router not supporting the TLV SHOULD just
silently ignore the TLV as specified in [RFC5250].
4.2. IS-IS Extensions
4.2.1. IS-IS TA TLV and TL TLV Format
The IS-IS TA sub-TLV and TL sub-TLV are used to advertise the TA and
TL a node belongs to. The IS-IS TA sub-TLV and TL sub-TLV are
advertised in IS-IS Router Capability TLV [RFC4971]).
The IS-IS TA sub-TLV and TL sub-TLV are composed of 1 octet for the
type, 1 octet specifying the TLV length and a value field. The
format of the IS-IS TA sub-TLV and TL sub-TLV for IPv4 and IPv6 are
as follows:
Sub-TLV:
ISIS IPv4 TYPE: TBD
ISIS IPv6 TYPE: TBD
Sub-TLV:
TE-Area TYPE: TBD
TE-Layer TYPE: TBD
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Li, et al. Expires March 28, 2014 [Page 12]
Internet-Draft OSPF for Auto TE Path Using TLs and TAs September 2013
Figure 4 IS-IS TE-Area sub-TLV and TE-Layer sub-TLV format
4.2.2. Elements of Procedure
The IS-IS TE-Area TLV and TE-Layer TLV are advertised within the IS-
IS Router CAPABILITY TLV defined in [RFC4971]. An IS-IS router MUST
originate a new IS-IS LSP whenever the content of any of the
advertised sub-TLV changes or whenever required by regular IS-IS
procedure (LSP updates). If an LSR desires to join or leave a
particular TE-Area or TE-Layer, it MUST originate a new LSP
comprising the refreshed IS-IS Router capability TLV with the updated
TE-Area sub-TLV and TE-Layer sub-TLV.
As specified in [RFC4971], a router may generate multiple IS-IS
Router CAPABILITY TLVs within an IS-IS LSP with different flooding
scopes. If the flooding scope of a TE-Area sub-TLV and TE-Layer sub-
TLV is limited to an IS-IS level, the sub-TLV MUST NOT be leaked
across level and the S flag of the Router CAPABILITY TLV MUST be
cleared. If the flooding scope of a TE-Area sub-TLV and TE-Layer
sub-TLV is the entire routing domain, the TLV MUST be leaked across
IS-IS levels, and the S flag of the Router CAPABILITY TLV MUST be
set. In both cases, the flooding rules specified in [RFC4971] apply.
4.2.3. Backward Compatibility
The IS-IS sub-TLVs defined in this document do not introduce any
interoperability issue. A router which does not support the sub-TLVs
SHOULD just silently ignore the sub-TLV as specified in [RFC6823].
5. IANA Considerations
5.1. OSPF
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 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
5.2. IS-IS
Li, et al. Expires March 28, 2014 [Page 13]
Internet-Draft OSPF for Auto TE Path Using TLs and TAs September 2013
The registry for the Router Capability TLV is defined in [RFC4971].
IANA assigned a new IS-IS sub-TLV code-point for the ISIS-TE-
Attributes TLVs sub-TLVs carried within the IS-IS Router Capability
TLV.
Value Sub-TLV References
----- -------- ----------
TBD ISIS-TE-Area TLV (IPv4) RFC 4971
TBD ISIS-TE-Layer TLV (IPv4) RFC 4971
TBD ISIS-TE-Area TLV (IPv6) RFC 4971
TBD ISIS-TE-Layer TLV (IPv6) RFC 4971
6. Security Considerations
TBD.
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.
[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.
[RFC4971] Vasseur, JP., Shen, N., and R. Aggarwal, "Intermediate
System to Intermediate System (IS-IS) Extensions for
Advertising Router Information", RFC 4971, July 2007.
[RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
OSPF Opaque LSA Option", RFC 5250, July 2008.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008.
[RFC6823] Ginsberg, L., Previdi, S., and M. Shand, "Advertising
Generic Information in IS-IS", RFC 6823, December 2012.
7.2. Informative Reference
[I-D.li-mpls-seamless-mpls-mbb]
Li, et al. Expires March 28, 2014 [Page 14]
Internet-Draft OSPF for Auto TE Path Using TLs and TAs September 2013
Li, Z., Li, L., Morillo, M., and T. Yang, "Seamless MPLS
for Mobile Backhaul", draft-li-mpls-seamless-mpls-mbb-00
(work in progress), July 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 March 28, 2014 [Page 15]
