TE Working Group Nabil Bitar
Internet Draft Roshan Rao
Expiration Date: December 2001 Karthik Muthukrishnan
Lucent Technologies Inc.
July 2001
Traffic Engineering Extensions to OSPF
draft-bitar-rao-ospf-diffserv-mpls-01.txt
Status
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document describes extensions to the traffic engineering opaque
LSA to mainly support differentiated services (Diffserv) and
Multiprotocol Label Switching (MPLS).
1. Introduction
In [1], a new OSPF Link State Advertisement (LSA), called the Traffic
Engineering LSA (TE-LSA), was defined. This LSA advertises the link
maximum and reservable bandwidth as well as the un-reservable
bandwidth at each of 8 priority levels.
This document defines new Link sub-TLV extensions to those defined in
[1] in order to support differentiated services and MPLS. The need or
requirements to provide such support in OSPF and IS-IS are discussed
in detail in [2]. Differentiated services (Diffserv) enable the
support of different per-hop behaviors (PHBs) [3] on a link. These
per-hop behaviors enable packets passing through a link to get
different forwarding treatment depending on the behavior aggregate to
which they belong. Each behavior aggregate maps to a PHB. MPLS-aware
switches/routers (LSRs), that implement the Diffserv extensions to
Bitar, et. al Expires December 2001 [Page 1]
MPLS [4], will be able to request and setup label-switched paths
(LSPs) that carry different behavior aggregates. At routers, the
label and/or EXP field of the top label in the shim header of a
labeled packet indicates the behavior aggregate to which the labeled
packet belongs. A Label Edge Router (LER) that initiates the setup of
an LSP and requests certain PHB(s) to be applied to that LSP should
be able to select a path through the network that is most likely to
satisfy its traffic engineering requirement, including the requested
PHB(s). This selection should be based on the state of the network,
i.e. link support for PHBs, bandwidth per link or per Diffserv class
etc. OSPF and IS-IS, as link state protocols, are perfectly suited to
distribute such information in the network. This document proposes
how encoding of such information can be done by extending the TE-LSA
defined in [1]. Some extensions similar to those proposed in this
document were proposed in [5]. However, this document defines the
actual encoding of these extensions based on the PHBIDs defined in
[6] as opposed to the class-type suggested in [5]. PHBIDs are used
to identify Diffserv PHB/PHB-groups in a standard way. Additionally,
the encoding proposed in this document can be looked at as defining
the class type in [5] as a concatenation of PHBIDs.
In addition to defining sub-TLVs that relay the link support for
Diffserv, a new Link sub-TLV is defined to advertise the MPLS
capability and the state of MPLS-related resources for that link.
It is also proposed that the Maximum reservable Bandwdth Link sub-TLV
defined in [1] be modified.
This document does not discuss how the actual route selection for an
LSP can be done. Route computation will be the subject of another
discussion.
2. TLV format
This document adopts the TLV format used in [1].
3. Link TLV
This document defines sub-TLVs to be encoded in the value field of
the link TLV defined in [1]. The following sub-TLVs are defined:
1- Diffserv Available Bandwidth
2- Oversubscription
3- Diffserv Capability
4- Diffserv Max Delay
5- Link Propagation Delay
6- Priority Reserved Bandwidth
7- Link Capability/Resources
All the sub-TLVs defined in this document are optional. However, a
router must support all Diffserv TLVs or none. Each sub-TLV may occur
only once. Unrecognized types are ignored but still flooded.
A Modification to the the defnition of the Maximum Reservable
Bandwidth sub-TLV defined in [1] is also proposed:
Bitar, et. al Expires December 2001 [Page 2]
3.1 Diffserv Available Bandwidth
The Diffserv Available Bandwidth sub-TLV is used to advertise the
available bandwidth for each PHB/PHB group or set of PHB/PHB-groups
configured on the advertised link from the advertising router
direction. In the latter case, a set of PHB/PHB groups is allocated
a sharable bandwidth chunk of the link. Each PHB or PHB group is
identified by a 16-bit PHB identifier (PHBID) [6]. The absence of a
PHBID from this sub-TLV can be interpreted to mean that the
particular PHB group is not supported on that link unless it is
advertised in the Diffserv capability TLV. Routing can take
advantage of this information in selecting a path for an LSP that
desires a particular PHB. The Diffserv available bandwidth sub-TLV
type is TBD. Its value consists of a sequence of elements where
each element 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|#PHB=n | Oversubscription | Available Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Available bandwidth(cont.) | PHBID1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ---------- | PHBIDn |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Each PHBID field is encoded according to RFC 2836 [6]. The bandwidth
value is encoded in IEEE floating point format and it is in units
of bytes per second. The available bandwidth is what is available
for reservation for the accompanying PHB, PHB group or set of
PHBs/PHB-groups advertised in each element. In the latter case, it
is assumed that a set of PHB/PHB groups advertised in one element
are allocated the same bandwidth chunk and have the same
oversubscription factor. Thus, allocating bandwidth X on the
advertised link for any of the listed PHB/PHB groups in that
element will decrease the available bandwidth for each of the
PHB/PHB groups in this list by X. The sum of all advertised
available bandwidths may exceed the actual link bandwidth as PHBs
or PHB groups can be oversubscribed. The advertised available
bandwidth factors in the over-subscription factor for a PHBID.
The oversubscription factor is included separately as it could be
used as a qualifier in selecting an LSP route (i.e. a route whose
link oversubscription for a PHB does not exceed a certain value).
The 10-bit over-subscription factor is encoded in percentage as an
unsigned integer value with a maximum value of 1023.
The number of elements advertised in each sub-TLV can be deduced
from the sub-TLV length and the #PHB field(s). Each element has
length (6 + n * 2) bytes, where 6 bytes account for the #PHB,
oversubscription and the available bandwidth fields, and n is the
number of PHBIDs advertised in that element.
3.2 Over-Subscription
Bitar, et. al Expires December 2001 [Page 3]
A Link TLV that includes the Over-Subscription sub-TLV MUST also
include the Maximum Reservable Bandwidth sub-TLV as proposed to be
defined in Section 3.8 and is correlated with it. The
Over-Subscription sub-TLV type is TBD. It is encoded in percentage
as a 16-bit integer value using 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Over-subscription factor | Reserved =0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Over-Subscription sub-TLV length is 4 bytes.
3.3 Diffserv Capability
The Diffserv Capability sub-TLV type is TBD. It is used to advertise
the PHB/PHB groups supported on a link. Its value consists of a
sequence of PHBIDs as follows:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHBID1 | PHBID2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ------ | ------ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ------ | PHBIDn |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Remember that the TLV must be 4-byte aligned. Thus, if n is odd, the
last 2 bytes will be padding bytes that are not included in the TLV
length. The PHBID field is encoded according to RFC2836. The number
of PHBIDs can be deduced from the length. If a PHBID is included in
an element in the Diffserv Available Bandwidth sub-TLV, it does not
need to be included in the Diffserv Capability sub-TLV. The Diffserv
Capability sub-TLV is used when it is desirable to advertise the
support for a PHB or a set of PHBs without advertising the bandwidth
associated with them.
3.4 Maximum Delay
It is sometimes desired to select a route for an LSP that satisfies
a delay variation and/or delay requirement. These requirements can
be imposed by the application(s) whose packets are to be transported
in that LSP. An operator may want to configure a Diffserv PHB/PHB
group that will be applied to such packets. Therefore, it becomes
important to advertise the maximum delay associated with that
PHB/PHB group at each link. When setting up an LSP with certain
delay/delay variation requirement, this maximum delay can be used
as a metric to select the LSP path. The Maximum delay advertised in
this sub-TLV is only due to queuing delay. The delay variation is
considered to be the same as maximum delay.
Bitar, et. al Expires December 2001 [Page 4]
The Maximum Delay TLV type is TBD. It is used to advertise the
maximum queuing delay that can be encountered by a packet that
belongs to a behavior aggregate corresponding to the associated
PHBID. Its value consists of a sequence of 4-octet elements where
each element 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PHBID | Max Delay value |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The Max Delay value is specified as an unsigned-integer in units of
microsecond. Thus, maximum delay can be 65536 microseconds. The
length field in the sub-TLV will be equal to (4* number of
advertised elements).
3.5 Link Propagation Delay
The Link Propagation Delay sub-TLV type is TBD. The delay value is
4 octets encoded in the value field of the sub-TLV in IEEE floating
point format. It is in units of microseconds.
3.6 Priority Reserved Bandwidth
This sub-TLV advertises the reserved bandwidth at each of the eight
priority levels specified in CR-LDP [7] and RSVP-TE [8]. An operator
may configure PHB(s)/PHB groups to have fixed allocations of the
bandwidth while allow others to share the remaining bandwidth or
chunks of the bandwidth. In addition, an operator can configure
certain priority levels but not all for certain PHB groups. In this
latter case, it makes sense to advertise the reserved bandwidth for
each of the configured priorities per PHB/PHB-group. When a set of
PHB/PHB-groups is advertised to have a sharable bandwidth (i.e.
as a set), the reserved bandwidth per priority level applies to the
set not to individual PHBs/PHB-groups.
This TLV type is TBD. Its value consists of a sequence of elements
where each element 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| #PHBID = n| Re| pri bit map | Reserved Bandwidth 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved Bandwidth 1 (cont.) | ------------ |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ---------- | ------------- |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ---------- | Reserved Bandwidth k |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved Bandwidth k (cont) | PHBID1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| --------------- | PHBIDn |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bitar, et. al Expires December 2001 [Page 5]
The priority bit map (pri bit map) corresponds to the priority level
with the most significant bit corresponding to priority 0 and the
least significant bit corresponding to priority 7. If the bit is
cleared, the corresponding priority level is not supported. If the
bit is set, the corresponding priority level is supported. For those
supported priority levels, the reserved bandwidth is listed in
decreasing priority order (i.e. starting with 0 down to 7). The
number of reserved bandwidth fields can be obtained by summing up
the number of 1's in the bit map.
3.7 Link Capability/Resources
The Link Capability/Resources sub-TLV type is TBD. Its value is a
32-bit map with the following defined bits:
Bit 0 (most significant bit): corresponds to MPLS-specific
resources on the link (e.g., out of labels, out of memory). It
is set when a resource essential to the setup of an LSP is
exhausted.
Bit 31: set to 1 if the router supports RSVP-TE. It is clear
otherwise.
Bit 30: set to 1 if the router supports CR-LDP. It is clear
otherwise.
3.8 Maximum Reservable Bandwidth
According to [1], the Maximum Reservable Bandwidth sub-TLV (type-7)
specifies the maximum bandwidth that may be reserved on this link in
this direction, in IEEE floating point format. It is proposed that
this sub-TLV advertise the maximum reservable bandwidth, including
oversubscription, on the link excluding what is advertised in the
Diffserv available bandwidth TLVs if any.
4. Elements of Procedure
This document adopts the elements of procedures in [1] but proposes
to eliminate the statement "No SPF or other route calculation are
necessary" in [1]. Whether SPF or other routing computations are to
be carried out upon reception of a type-10 LSA will depend on the
router capabilities in supporting the TE extensions and its
configuration, an implementation issue. Consistent routing behavior
is probably better attained if all routers in a domain use the same
criteria and algorithms for computing their routing tables. Routers
shall reoriginate Traffic Engineering LSAs, other than normal
refreshes, whenever there is a significant change in the advertised
information that was previously advertised by these LSAs.
5. Security Considerations
This document raises no new security issues for OSPF.
Bitar, et. al Expires December 2001 [Page 6]
6. References
[1] Katz, Dave and Yeung, Derek, "Traffic Engineering Extensions to
OSPF," draft-katz-yeung-ospf-traffic-04.txt, February 2001.
[2] Le Faucheur et. al., "Requirements for support of
Diff-Serv-aware MPLS Traffic Engineering," draft-ietf-tewg-diff-
te-reqts-00.txt," February 2001.
[3] Blake, S. et. al., "An Architecture for Differentiated Services,"
RFC 2475, December 1998.
[4] Le Faucheur et. al., "MPLS Support of Differentiated Services,"
draft-ietf-mpls-diff-ext-08.txt, February 2001.
[5] Le Faucheur et. al., " Extensions to OSPF for support of
Diff-Serv-aware MPLS Traffic Engineering," draft-ietf-ospf-diff-
te-00.txt, February 2001.
[6] Brim, S. et al, "Per Hop Behavior Identification Codes,"
RFC 2836, May 2000.
[7] Jamoussi, B. et. al. "Constraint-Based LSP Setup using LDP,"
draft-ietf-mpls-cr-ldp-05.txt, February 2001.
[8] Awduche, D. et al, "RSVP-TE: Extensions to RSVP for LSP Tunnels,"
draft-ietf-mpls-rsvp-lsp-tunnel-08.txt, February 2001.
Authors' addresses:
Nabil Bitar
Lucent Technologies
1 Robbins Road,
Westford, MA 01889
USA
E-mail: nbitar@lucent.com
Roshan Rao
Lucent Technologies
1 Robbins Road,
Westford, MA 01889
USA
E-mail: rrao@lucent.com
Karthik Muthukrishnan
Lucent Technologies
1 Robbins Road,
Westford, MA 01889
USA
E-mail: mkarthik@lucent.com
Bitar, et. al Expires December 2001 [Page 7]
