IDR Working Group Q. Wu
Internet-Draft D. Wang
Intended status: Standards Track Huawei
Expires: January 30, 2014 July 29, 2013
BGP attribute for North-Bound Distribution of Traffic Engineering (TE)
performance Metric
draft-wu-idr-te-pm-bgp-01
Abstract
In order to populate network performance information like link
latency, latency variation and packet loss into Traffic Engineering
Database(TED) and ALTO server, this document describes extensions to
BGP protocol, that can be used to distribute network performance
information (such as link delay, delay variation, packet loss,
residual bandwidth, and available bandwidth, link utilization,
channel throughput).
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 January 30, 2014.
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
Wu & Wang Expires January 30, 2014 [Page 1]
Internet-Draft BGP for TE performance July 2013
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. Conventions used in this document . . . . . . . . . . . . . . 4
3. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. MPLS-TE with PCE . . . . . . . . . . . . . . . . . . . . . 5
3.2. ALTO Server Network API . . . . . . . . . . . . . . . . . 5
4. Carrying TE Performance information in BGP . . . . . . . . . . 7
5. Attribute TLV Details . . . . . . . . . . . . . . . . . . . . 9
5.1. Link Utilization TLV . . . . . . . . . . . . . . . . . . . 10
5.2. Channel Throughput TLV . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 12
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14
8.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
Wu & Wang Expires January 30, 2014 [Page 2]
Internet-Draft BGP for TE performance July 2013
1. Introduction
As specified in [RFC4655],a Path Computation Element (PCE) is an
entity that is capable of computing a network path or route based on
a network graph, and of applying computational constraints during the
computation In order to compute an end to end path, the PCE needs to
have a unified view of the overall topology[I-D.ietf-pce-pcep-
service-aware]. [I.D-ietf-idr-ls- distribution] describes a
mechanism by which links state and traffic engineering information
can be collected from networks and shared with external components
using the BGP routing protocol. This mechanism can be used by both
PCE and ALTO server to gather information about the topologies and
capabilities of the network.
With the growth of network virtualization technology, the needs for
inter-connection between various overlay technologies (e.g.
Enterprise BGP/MPLS IP VPNs) in the Wide Area Network (WAN) become
important. The Network performance or QoS requirements such as
latency, limited bandwidth, packet loss, and jitter, are all critical
factors that must be taken into account in the end to end path
computation ([I-D.ietf-pce-pcep-service-aware])and selection to
establish segment overlay tunnel between overlay nodes and stitch
them together to compute end to end path.
In order to populate network performance information like link
latency, latency variation and packet loss into TED and ALTO server,
this document describes extensions to BGP protocol, that can be used
to distribute network performance information (such as link delay,
delay variation, packet loss, residual bandwidth, and available
bandwidth,link utilization, channel throughput).
Wu & Wang Expires January 30, 2014 [Page 3]
Internet-Draft BGP for TE performance July 2013
2. Conventions used in this document
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 [RFC2119].
Wu & Wang Expires January 30, 2014 [Page 4]
Internet-Draft BGP for TE performance July 2013
3. Use Cases
3.1. MPLS-TE with PCE
The following figure shows how a PCE can get its TE performance
information beyond that contained in the LINK_STATE attributes [I.D-
ietf-idr-ls-distribution] using the mechanism described in this
document.
+----------+ +---------+
| ----- | | BGP |
| | TED |<-+-------------------------->| Speaker |
| ----- | TED synchronization | |
| | | mechanism: +---------+
| | | BGP with TE performance
| v | NLRI
| ----- |
| | PCE | |
| ----- |
+----------+
^
| Request/
| Response
v
Service +----------+ Signaling +----------+
Request | Head-End | Protocol | Adjacent |
-------->| Node |<------------>| Node |
+----------+ +----------+
Figure 1: External PCE node using a TED synchronization mechanism
3.2. ALTO Server Network API
The following figure shows how an ALTO Server can get TE performance
information from the underlying network beyond that contained in the
LINK_STATE attributes [I.D-ietf-idr-ls-distribution] using the
mechanism described in this document.
Wu & Wang Expires January 30, 2014 [Page 5]
Internet-Draft BGP for TE performance July 2013
+--------+
| Client |<--+
+--------+ |
| ALTO +--------+ BGP with +---------+
+--------+ | Protocol | ALTO | TE Performance | BGP |
| Client |<--+------------| Server |<----------------| Speaker |
+--------+ | | | NLR | |
| +--------+ +---------+
+--------+ |
| Client |<--+
+--------+
Figure 2: ALTO Server using network performance information
Wu & Wang Expires January 30, 2014 [Page 6]
Internet-Draft BGP for TE performance July 2013
4. Carrying TE Performance information in BGP
This document proposes new BGP TE performance TLVs that can be
announced as attribute in the BGP-LS attribute (defined in [I.D-ietf-
idr- ls-distribution]) to distribute network performance information.
The extensions in this document build on the ones provided in BGP-LS
[I.D -ietf-idr-ls-distribution] and BGP-4 [RFC4271].
BGP-LS attribute defined in [I.D-ietf-idr-ls-distribution] has nested
TLVs which allow the BGP-LS attribute to be readily extended. This
document proposes seven additional TLVs as its attributes:
Type Value
TBD1 Unidirectional Link Delay
TBD2 Unidirectional Delay Variation
TBD3 Unidirectional Packet Loss
TBD4 Unidirectional Residual Bandwidth
TBD5 Unidirectional Available Bandwidth
TBD6 Link Utilization
TBD7 Channel Throughput
As can be seen in the list above, the TLVs described in this document
carry different types of network performance information. Many (but
not all) of the TLVs include a bit called the Anomalous (or "A") bit.
When the A bit is clear (or when the TLV does not include an A bit),
the TLV describes steady state link performance. This information
could conceivably be used to construct a steady state performance
topology for initial tunnel path computation, or to verify
alternative failover paths.
When network performance downgrades and falls below configurable
link-local thresholds a TLV with the A bit set is advertised. These
TLVs could be used by the receiving node to determine whether to
redirect failing traffic to a backup path, or whether to calculate an
entirely new path. If link performance improves later and exceeds a
configurable minimum value (i.e.,threshold), that TLV can be re-
advertised with the Anomalous bit cleared. In this case, a receiving
node can conceivably do whatever re-optimization (or failback) it
wishes to do (including nothing).
Note that when a TLV does not include the A bit, that sub-TLV cannot
Wu & Wang Expires January 30, 2014 [Page 7]
Internet-Draft BGP for TE performance July 2013
be used for failover purposes. The A bit was intentionally omitted
from some TLVs to help mitigate oscillations.
Consistent with existing ISIS TE specifications [RFC5305][ISIS-TE-
METRIC], the bandwidth advertisements defined in this document MUST
be encoded as IEEE floating point values. The delay and delay
variation advertisements defined in this draft MUST be encoded as
integer values. Delay values MUST be quantified in units of
microseconds, packet loss MUST be quantified as a percentage of
packets sent, and bandwidth MUST be sent as bytes per second. All
values (except residual bandwidth) MUST be calculated as rolling
averages where the averaging period MUST be a configurable period of
time.
Wu & Wang Expires January 30, 2014 [Page 8]
Internet-Draft BGP for TE performance July 2013
5. Attribute TLV Details
Link attribute TLVs defined in section 3.2.2 of [I-D. ietf-idr-ls-
distribution]are TLVs that may be encoded in the BGP-LS attribute
with a link NLRI. Each 'Link Attribute' is a Type/Length/ Value
(TLV) triplet formatted as defined in Section 3.1 of [I-D.ietf- idr-
ls-distribution]. The format and semantics of the 'value' fields in
some 'Link Attribute' TLVs correspond to the format and semantics of
value fields in IS-IS Extended IS Reachability sub-TLVs, defined in
[RFC5305]. Although the encodings for 'Link Attribute' TLVs were
originally defined for IS-IS, the TLVs can carry data sourced either
by IS-IS or OSPF.
The following 'Link Attribute' TLVs are valid in the LINK_STATE
attribute:
+------------+---------------------+--------------+-----------------+
| TLV Code | Description | IS-IS | Defined in: |
| Point | | TLV/Sub-TLV | |
+------------+---------------------+--------------+-----------------+
| xxxx | Unidirectional | 22/xx | [ISIS-TE]/4.1 |
| | Link Delay | | |
| | | | |
| xxxx | Min/Max Unidirection| 22/xx | [ISIS-TE]/4.2 |
| | Link Delay | | |
| | | | |
| xxxx | Unidirectional | 22/xx | [ISIS-TE]/4.3 |
| | Delay Variation | | |
| | | | |
| xxxx | Unidirectional | 22/xx | [ISIS-TE]/4.4 |
| | Link Loss | | |
| | | | |
| xxxx | Unidirectional | 22/xx | [ISIS-TE]/4.5 |
| |Residual Bandwidth | | |
| | | | |
| xxxx | Unidirectional | 22/xx | [ISIS-TE]/4.6 |
| |Available Bandwidth | | |
| | | | |
| xxxx | Link Utilization | ---- | section 5.1 |
| | | | |
| xxxx | Channel Throughput | ---- | section 5.2 |
+------------+---------------------+--------------+-----------------+
Table 1: Link Attribute TLVs
Wu & Wang Expires January 30, 2014 [Page 9]
Internet-Draft BGP for TE performance July 2013
5.1. Link Utilization TLV
This TLV advertises the average link utilization between two directly
connected IS-IS neighbors. The link utilization advertised by this
sub-TLV MUST be the utilization percentage per interval from the
local neighbor to the remote one. The format of this sub-TLV is
shown in the following diagram:
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Utilization |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
Type: TBA
Length: 4
Link Utilization. This 24-bit field carries the average
link untilization over a configurable interval. A commonly
used time interval is 5 minutes, and this interval has been
sufficient to support network operations and design for some
time. link utilization can be calculated by counting the
IP-layer (or other layer) octets received over a time interval
and dividing by the theoretical maximum number of octets that
could have been delivered in the same interval(see section6.4
of [RFC6703]). If there is no value to send (unmeasured and
not statically specified), then the sub-TLV should not be sent
or be withdrawn.
5.2. Channel Throughput TLV
This TLV advertises the average Channel Throughput between two
directly connected IS-IS neighbors. The channel throughput
advertised by this sub-TLV MUST be the throughput between the local
neighbor and the remote one. The format of this sub-TLV is shown in
the following diagram:
Wu & Wang Expires January 30, 2014 [Page 10]
Internet-Draft BGP for TE performance July 2013
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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Throughput Offered |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Throughput Delivered |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
where:
Type: TBA
Length: 8
Throughput offered: This 24-bit field carries the average
throughput offered over a configurable interval. Throughput
offered can be calculated by counting the number of
units successfully transmitted in the interval
(See section 2.3 of [RFC6374)). If there is no value to
send (unmeasured and not statically specified), then
the sub-TLV should not be sent or be withdrawn.
Throughput delivered: This 24-bit field carries the average
throughput delivered over a configurable interval.
Throughput delivered can be calculated by counting the
number of units successfully received in the interval
(See section 2.3 of [RFC6374)). If there is no value
to send (unmeasured and not statically specified),
then the sub-TLV should not be sent or be withdrawn.
Wu & Wang Expires January 30, 2014 [Page 11]
Internet-Draft BGP for TE performance July 2013
6. Security Considerations
This document does not introduce security issues beyond those
discussed in [I.D-ietf-idr-ls-distribution] and [RFC4271].
Wu & Wang Expires January 30, 2014 [Page 12]
Internet-Draft BGP for TE performance July 2013
7. IANA Considerations
IANA maintains the registry for the TLVs. BGP TE Performance TLV
will require one new type code per TLV defined in this document.
Wu & Wang Expires January 30, 2014 [Page 13]
Internet-Draft BGP for TE performance July 2013
8. References
8.1. Normative References
[I-D.ietf-idr-ls-distribution]
Gredler, H., "North-Bound Distribution of Link-State and
TE Information using BGP",
ID draft-ietf-idr-ls-distribution-03, May 2013.
[I-D.ietf-pce-pcep-service-aware]
Dhruv, D., "Extensions to the Path Computation Element
Communication Protocol (PCEP) to compute service aware
Label Switched Path (LSP)",
ID draft-ietf-pce-pcep-service-aware-01, July 2013.
[ISIS-TE-METRIC]
Giacalone, S., "ISIS Traffic Engineering (TE) Metric
Extensions", ID draft-ietf-isis-te-metric-extensions-00,
June 2013.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", March 1997.
[RFC4271] Rekhter, Y., "A Border Gateway Protocol 4 (BGP-4)",
RFC 4271, January 2006.
[RFC5305] Li, T., "IS-IS Extensions for Traffic Engineering",
RFC 5305, October 2008.
8.2. Informative References
[ALTO] Yang, Y., "ALTO Protocol",
ID http://tools.ietf.org/html/draft-ietf-alto-protocol-16,
May 2013.
[RFC4655] Farrel, A., "A Path Computation Element (PCE)-Based
Architecture", RFC 4655, August 2006.
Wu & Wang Expires January 30, 2014 [Page 14]
Internet-Draft BGP for TE performance July 2013
Authors' Addresses
Qin Wu
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: sunseawq@huawei.com
Danhua Wang
Huawei
101 Software Avenue, Yuhua District
Nanjing, Jiangsu 210012
China
Email: wangdanhua@huawei.com
Wu & Wang Expires January 30, 2014 [Page 15]