Traffic Engineering Extensions to OSPF Version 3
RFC 5329

• Status
• IESG evaluation record
• IESG writeups
• Email expansions
• History

• Versions
• 13

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 2008

Table 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 2008

2.  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             |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Link State ID                              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                    Advertising Router                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+