One document matched: draft-yeung-ospf-traffic-00.txt
Network Working Group Derek M. Yeung
Internet Draft Cisco Systems
Expiration Date: August 1999 Februrary 1999
OSPF Extensions for Traffic Engineering
draft-yeung-ospf-traffic-00.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.
1. Abstract
This document describes extensions to the OSPF protocol to support
Traffic Engineering [1]. The OSPF protocol is specified in [2], This
extension make use of opaque LSA defined in [3] and provides similar
information to what is defined in the ISIS extensions for traffic
engineering[4].
This document extends the OSPF protocol by specifying new information
that a router can place in a type 10 opaque Link State Advertisement
(LSA). This information describes additional information about the
state of the network that is useful for traffic engineering.
Yeung [Page 1]
Internet Draft draft-yeung-ospf-traffic-00.txt Februrary 1999
2. Introduction
OSPF Opaque LSA provides a generalized mechanism for OSPF to carry
additional information. The new information can be used directly by
OSPF or indirectly by other applications which use OSPF to distribute
information. This document defines how to use opaque LSA to carry
additional information for traffic engineering.
Opaque LSA consists of a standard LSA header followed by a 32-bit
aligned application-specific information field. The link-state type
field identifies the flooding scope; type 9 for link-local, type 10
for area-local and type 11 for AS. This document uses type 10 area-
local flood scope to distribute the LSA. In order words, the traffic
engineering (TE) LSA is flooded only within the same area. Handling
the traffic engineering information across multiple areas is outside
the scope of this document.
The TE LSA opaque data is divided into a number of tuples, each
consisting of a Type, a Length and a Value. The general definition of
TLV is used, except that the Length field size depends on the Type
field. This document call this variant as TVLV (See section 4.0).
TVLV is flexible and provide an easy way to extend the information
carried in the TE opaque LSA.
This document defines a set of TVLVs that carry information about the
characteristics of a particular link. It also defines a router
address TVLV which is useful for traffic engineering. Moreover, the
document defines a padding TVLV. This TVLV fulfills the 32-bit
alignment requirement of OSPF LSA. Finally, it also defines a TVLV
for future extensions.
This document only defines the layout of traffic engineering
information in the opaque LSA using TVLV. Unless stated otherwise,
procedures for obtaining this information, and the use of this
information (either within or outside of OSPF) is outside the scope
of this document.
Yeung [Page 2]
Internet Draft draft-yeung-ospf-traffic-00.txt Februrary 1999
3. OSPF Traffic Engineering LSA format
Type 10 area-scope opaque LSA is used to carry the traffic
engineering information. The opaque type is 168. The content of the
LSA is represented in a group of TVLVs (See below).
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 10 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 168 | TE LSA ID | LSA Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VARIABLE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
/ /
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VARIABLE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The opaque ID of the TE LSA is divided into a 2-octets of TE LSA ID
and a 1-octet of LSA number.
The TE LSA ID is generated from the advertising router ID and is used
to indentify the TE opaque LSAs generated by a particular OSPF
instance within an area. For example, it could be the last two bytes
of the advertising router ID. If different routers happen to use the
same TE LSA ID, their TE LSAs are still distinguishable by the
advertising router ID. Other mechanisms can be used to generate a
unique TE LSA ID.
The LSA number allows us to generate multiple LSAs for traffic
engineering without consuming new opaque types. The LSA number must
start with 0. Moreover, TE LSAs with LSA number 0 must present in
the database before other LSA fragments with the same TE LSA ID but
different non-zero LSA number are considered in the route
calculation.
Yeung [Page 3]
Internet Draft draft-yeung-ospf-traffic-00.txt Februrary 1999
4. Extended TLV (TVTV)
In a normal TLV, the size of the type and length fields is fixed in
1-octet. Although 256 different types seems sufficient, 255 octets as
the maximum length is a potential limitation. However, making the
length field two octets could be too large in certain cases. To solve
this problem this document allows the size of the length field to be
variable. The TLVs with the variable size Length field are referred
in this document as TVLV (Type- Variable Length - Value).
In a TVLV the size of the length field depends on the type. Only two
lengths is supported; 1 or 2 octets. Since the OSPF LSA length in the
LSA header is only 2 octets, it does not make sense to has a length
more than 2 octets for the TVLV.
Type Type size Length size Content
0-127 1-octet 1-octet VARIABLE
128-255 1-octet 2-octets VARIABLE
TVLV provides more flexibility for OSPF than normal TLV. Using the
neighbor TVLV (See section 7.0) as an example, the TVLV allows more
sub-TVLVs to be added than the TLV. Moreover, given that the maximum
size of an OSPF LSA is 64k bytes, a single neighbor TVLV, instead of
multiple TLVs, is sufficient to fill up the LSA. This result in less
space being wasted in the TLV header.
5. Padding TVLV
The padding TVLV is TVLV type 0.
Padding is used to algin OSPF LSA on a 32-bit alignment. The padding
TVLV, if it is required, should be used as the last TVLV.
The size of the length field is 1-octet.
Type Length (Octets) Value (Octets)
0 1 Variable
Yeung [Page 4]
Internet Draft draft-yeung-ospf-traffic-00.txt Februrary 1999
6. Router Address TVLV
The router address TVLV is TVLV type 1.
The router address TVLV contains the 4-octet IP address of the router
originating the LSA. The length field size is 1-octet.
Type Length (Octets) Value (Octets)
1 1 4
For traffic engineering, it guarantees that we have a single stable
address that can always be referenced in a path that will be
reachable from multiple hops away, regardless of the state of the
node's interfaces.
7. Neighbor TVLV
The neighbor TVLV is TVLV type 128.
It describes a series of neighbors in the traffic engineering
topology. The value field has a variable length.
Type Length (Octets) Value (Octets)
128 2 11+
For each neighbor, it contains the link type, link ID, metric, size
of sub-TVLVs and zero or more sub-TVLVs. The sub-TVLVs can be used to
provide addtional information.
Link Type 1-octet; 1 for p2p, 2 for multi-access
Link ID 4-octets
Metric 4-octets
Length of Sub-TVLV 2-octets
0-65504 octets of sub-TVLVs
The link type specify the characteristics of the link. It also
affects the meaning of the link ID field. Currently, point-to-point
and multi-access types are defined.
For point-to-point links, the link ID is the OSPF router ID of the
neighbor. In other words, it is the link state ID of the neighbor's
router LSA.
For multi-access links, the link ID is the IP address of designated
router for the link. In other words, it is the link state ID of the
designated router's network LSA.
Yeung [Page 5]
Internet Draft draft-yeung-ospf-traffic-00.txt Februrary 1999
This document does not define any equivalent of the network LSA to
describe multi-access links. Instead, it makes use of the network LSA
defined for normal OSPF. When the neighbor TVLV is generated, the
existence of any network LSA and designated router should be taken
into account so the link type and link ID can be set correctly.
The metric is administratively assigned and can be used to present a
differently weighted topology to traffic engineering SPF
calculations.
The length of the sub-TVLVs is calculated by the maximum LSA length
(65535) minus LSA header size (20) minus neighbor TVLV fixed portion
(11).
This data structure can be repeated in the same neighbor TVLV to
describe more than one neighbor.
The following sub-TVLVs are proposed.
Sub-TVLV
type Length (Octets) Value (Octets) Name
1 1 4 Interface address
2 1 4 Neighbor address
3 1 4 Maximum link bandwidth
4 1 2 Maximum Allocation Multiplier
5 1 32 Current bandwith reservation
6 1 4 Resource class
Each of the sub-TVLVs is described below. Unless stated otherwise,
multiple occurrences of the information are supported by mulitple
inclusions of the sub-TLV.
7.1. Sub-TVLV 1: Interface address
This sub-TVLV contains a 4-octet IPv4 address for the interface
described by the (main) TVLV. This sub-TVLV can occur multiple
times.
If a router implements traffic engineering, it must include this
TVLV.
Yeung [Page 6]
Internet Draft draft-yeung-ospf-traffic-00.txt Februrary 1999
7.2. Sub-TVLV 2: Neighbor address
This sub-TVLV contains a single IPv4 address for a neighboring router
on this link. This sub-TLV can occur multiple times.
This TVLV is useful for diagnostic purposes.
7.3. Sub-TVLV 3: Maximum link bandwidth
This sub-TVLV contains the maximum bandwidth on this link in this
direction (from the router originating the LSA to its neighbors).
The bandwidth is encoded in 32 bits in IEEE floating point format.
The units are bytes (not bits!) per second.
7.4. Sub-TVLV 4: Maximum Allocation Multiplier
This sub-TVLV contains the percentage of the maximum link bandwidth
that can be reserved. This percentage is encoded as a 2-octet
unsigned integer. Thus, this field can indicate that 0% of the link
bandwidth up to 65,535% of the link bandwidth (note that for
oversubscription purposes, this can be greater than 100%).
7.5. Sub-TVLV 5: Current bandwidth reservation
This sub-TVLV contains the amount of bandwidth currently reserved in
this direction on this link. Note that for oversubscription
purposes, this can be greater than the bandwidth of the link. This
is encoded similarly to the maximum link bandwidth.
Because of the need for priority and preemption, each originator of a
Label Switched Path needs to know the amount of reserved bandwidth at
each priority level. Thus, this sub-TVLV contains eight 32 bit IEEE
floating point numbers. The units are bytes (not bits!) per second.
The values correspond to the bandwidth reserved with a holding of
priority 0 through 7, arranged in increasing order with priority 0
occurring at the start of the sub-TVLV, and priority 7 at the end of
the sub-TVLV.
For stability reasons, rapid changes in the values in this sub-TVLV
should not cause rapid generation of LSAs.
Yeung [Page 7]
Internet Draft draft-yeung-ospf-traffic-00.txt Februrary 1999
7.6. Sub-TVLV 6: Resource class (color, administrative group)
The administrative group sub-TVLV contains a 4-octet bit mask
assigned by the network administrator. Each set bit corresponds to
one administrative group assigned to the interface.
By convention the least significant bit is referred to as 'group 0',
and the most significant bit is referred to as 'group 31'.
8. Extension TVLV
Extension TVLV is TVLV type 255.
The TVLV is reserved for future extension. For example, if we run out
of type, we can use this to create another 255 types. Length field
size is 2-octets.
Type Length Value (Octets)
255 2 Variable
9. Security Considerations
This document raises no new security issues for OSPF.
10. Acknowledgments
The author would like to thank Yakov Rekhter, Read Bell, Henk Smit
and Jim Gibson for their helpful comments on this work. The author
also like to recognize [4] as the inspiration of this work.
Yeung [Page 8]
Internet Draft draft-yeung-ospf-traffic-00.txt Februrary 1999
11. References
[1] draft-ietf-mpls-traffic-eng-00.txt, "Requirements for Traffic
Engineering Over MPLS", D. Awduche, J. Malcolm, J. Agogbua, M.
O'Dell, J. McManus, work in progress.
[2] RFC 2328 OSPF Version 2. J. Moy. April 1998. (Format: TXT=447367
bytes) (Obsoletes RFC2178) (Also STD0054) (Status: STANDARD)
[3] RFC 2370 The OSPF Opaque LSA Option. R. Coltun. July 1998.
(Format: TXT=33789 bytes) (Also RFC2328) (Status: PROPOSED STANDARD)
[4] draft-ietf-isis-traffic-00.txt, "ISIS Extensions for Traffic
Engineering", H. Smit, T. Li, work in progress.
12. Authors' Addresses
Derek M. Yeung
Cisco Systems, Inc.
210 West Tasman Drive
San Jose, CA 95134
Email: myeung@cisco.com
Voice: +1 408 526 8019
Yeung [Page 9]
| PAFTECH AB 2003-2026 | 2026-04-22 06:17:53 |