Network Working Group K. Ishiguro
Request for Comments: 5329 V. Manral
Category: Standards Track IP Infusion, Inc
A. Davey
Data Connection Limited
A. Lindem, Ed.
Redback Networks
September 2008
Traffic Engineering Extensions to OSPF Version 3
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The IETF Trust (2008).
Abstract
This document describes extensions to OSPFv3 to support intra-area
Traffic Engineering (TE). This document extends OSPFv2 TE to handle
IPv6 networks. A new TLV and several new sub-TLVs are defined to
support IPv6 networks.
Ishiguro, et al. Standards Track [Page 1]RFC 5329 OSPFv3-Traffic Engineering September 2008Table of Contents
1. Introduction ....................................................2
1.1. Requirements Notation ......................................2
2. Intra-Area-TE-LSA ...............................................3
2.1. Intra-Area-TE-LSA Payload ..................................4
3. Router IPv6 Address TLV .........................................4
4. Link TLV ........................................................5
4.1. Link ID Sub-TLV ............................................6
4.2. Neighbor ID Sub-TLV ........................................6
4.3. Local Interface IPv6 Address Sub-TLV .......................6
4.4. Remote Interface IPv6 Address Sub-TLV ......................7
5. Security Considerations .........................................8
6. Management Considerations .......................................8
7. IANA Considerations .............................................9
8. References ......................................................9
8.1. Normative References .......................................9
8.2. Informative References ....................................10
Acknowledgments ...................................................10
1. Introduction
OSPFv3 has a very flexible mechanism for adding new LS types.
Unknown LS types are flooded properly based on the flooding scope
bits in the LS type [OSPFV3]. This document defines the Intra-Area-
TE-LSA to OSPFv3.
For Traffic Engineering, this document uses "Traffic Engineering
Extensions to OSPF" [TE] as a base for TLV definitions. New TLVs and
sub-TLVs are added to [TE] to extend TE capabilities to IPv6
networks. Some existing TLVs and sub-TLVs require clarification for
OSPFv3 applicability.
GMPLS [GMPLS] and the Diff-Serv MPLS extensions [TE-DIFF] are based
on [TE]. These functions can also be extended to OSPFv3 by utilizing
the TLVs and sub-TLVs described in this document.
1.1. Requirements Notation
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
[RFC-KEYWORDS].
Ishiguro, et al. Standards Track [Page 2]RFC 5329 OSPFv3-Traffic Engineering September 20082. Intra-Area-TE-LSA
A new LS type is defined for the Intra-Area-TE-LSA. This is
different from OSPFv2 Traffic Engineering [TE] where opaque LSAs are
used to advertise TE information [OPAQUE]. The LSA function code is
10, the U-bit is set, and the scope is set to 01 for area-scoping.
When the U-bit is set to 1, an OSPFv3 router must flood the LSA at
its defined flooding scope even if it does not recognize the LS type
[OSPFV3].
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 |1|0|1| 10 |
datatracker.ietf.org