[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02

Network Working Group                                       K. Ishiguro
Internet Draft                                         IP Infusion Inc.
Expiration Date: September 2003                               T. Takada
                                                       IP Infusion Inc.
                                                             March 2003


            Traffic Engineering Extensions to OSPF version 3

               draft-ishiguro-ospf-ospfv3-traffic-02.txt


Status of this Memo

   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 OSPF version 3 to support
   intra-area Traffic Engineering [RFC2702].  The OSPFv3 protocol is
   specified in [RFC2740].

   This document expands [OSPFV2-TE] to make both IPv4 and IPv6 network
   applicable.  New sub-TLVs are defined to support IPv6 network.  Use
   of these new sub-TLVs are not limited in OSPF version 3.  They can be
   used in OSPF version 2.


1. Applicability




Ishiguro                 Expires September 2003                 [Page 1]


Internet Draft  draft-ishiguro-ospf-ospfv3-traffic-02.txt     March 2003


   OSPFv3 has a very flexible mechanism in terms of adding new LS type.
   Even the implementation does not know the LS types, the LSA is
   properly flooded by LS type field.  This document adds a new LSA type
   Intra-Area-TE-LSA to OSPFv3.

   For Traffic Engineering, this document refers [OSPFV2-TE] as a
   basement TLV definition documentation.  New sub-TLVs are added to
   [OSPFV2-TE] to provide applicability to OSPFv3.  Some TLVs need
   clarification of their usage and value to apply to OSPFv3.  Newly
   added sub-TLVs can be used in [OSPFV2-TE] also.

   Once [OSPFV2-TE] becomes applicable to OSPFv3, other mechanism such
   as [OSPF-GMPLS] and [DIFFSERV-TE] which use [OSPFV2-TE] can be
   applicable to OSPFv3.


2. Router Address TLV

   In OSPFv3, Router Address TLV value should be a Router ID of the
   advertising router.  [OSPFV2-TE] states Router Address TLV is "a
   stable IP address of the advertising router that is always reachable
   if there is any connectivity to it".  In OSPFv3, Router ID is not a
   real IP address and is not reachable in IPv6 network.  In OSPFv3
   router identifier and IP address is completely separated.  For
   eachability information, Router IPv6 Address TLV is used.

   The Router Address TLV is type 1, and has a length of 4, and the
   value is the four octet OSPFv3 Router ID.  It must appear in exactly
   one Traffic Engineering LSA originated by a router.


3. Router IPv6 Address TLV

   A new TLV is introduced to carry reachable IPv6 address.  This IPv6
   address is always reachable address to resolve the router's
   reachability.

   The Router IPv6 Address TLV is type 3, and has a length of 16.  It
   must appear in exactly one Traffic Engineering LSA originated by a
   router.


4. Link TLV

   The Link TLV describes a single link.  It is constructed of a set of
   sub-TLVs.  Except Link ID sub-TLV, all of other sub-TLVs defined in
   [OSPFV2-TE] can be applicable to OSPFv3.  Link ID sub-TLV can't be
   used in OSPFv3 due to the protocol difference between OSPFv2 and



Ishiguro                 Expires September 2003                 [Page 2]


Internet Draft  draft-ishiguro-ospf-ospfv3-traffic-02.txt     March 2003


   OSPFv3.

   Three new sub-TLVs are defined in this document: Neighbor ID, Local
   Interface IPv6 address and Remote Interface IPv6 address.


     17 - Neighbor ID (8 octets)
     18 - Local Interface IPv6 Address (16N octets)
     19 - Remote Interface IPv6 Address (16N octets)



4.1 Link ID

   Link ID sub-TLV is used in OSPFv2 to identify the other end of the
   link.  In OSPFv3, Neighbor ID should be used instead of Link ID.  In
   OSPFv3, the Link ID sub-TLV should not be sent and ignored upon
   receipt.

4.2 Neighbor ID

   In OSPFv2, Link ID is a unique key to identify the other end of the
   link.  In OSPFv3, to identify the other end of the link, the combina-
   tion of Neighbor Interface ID and Neighbor Router ID is needed.  So
   new sub-TLV Neighbor ID is defined.

   The Neighbor ID sub-TLV is TLV type 17, and is 8 octets in length.
   It contains 4 octet Neighbor Interface ID and 4 octet Neighbor Router
   ID.  Neighbor Interface ID and Neighbor Router ID value is the same
   as described in [OSPFV3] A.4.3 Router-LSAs.

   In OSPFv2, the Neighbor ID sub-TLV should not be sent and ignored
   upon receipt.

4.3 Local Interface IPv6 Address

   The Local Interface IPv6 Address sub-TLV specifies the IPv6
   address(es) of the interface corresponding to this link.  If there
   are multiple local addresses on the link, they are all listed in this
   sub-TLV.  Link-local address should not be included in this sub-TLV.

   The Local Interface IPv6 Address sub-TLV is TLV type 18, and is 16N
   octets in length, where N is the number of local addresses.


4.4 Remote Interface IPv6 Address

   The Remote Interface IPv6 Address sub-TLV specifies the IPv6



Ishiguro                 Expires September 2003                 [Page 3]


Internet Draft  draft-ishiguro-ospf-ospfv3-traffic-02.txt     March 2003


   address(es) of the neighbor's interface corresponding to this link.
   This and the local address are used to discern multiple parallel
   links between systems.  If the Link Type of the link is Multiaccess,
   the Remote Interface IPv6 Address is set to ::.  Link-local address
   should not be included in this sub-TLV.

   The Remote Interface IPv6 Address sub-TLV is TLV type 19, and is 16N
   octets in length, where N is the number of neighbor addresses.


5. Intra-Area-TE-LSA

   New LS type Intra-Area-TE-LSA is defined.  LSA function code is 10.
   U bit is 1 to indicate that router should handle the LSA even if the
   router does not recognize the LSA's function code.  Flooding scope is
   Area Scoping.  So Intra-Area-TE-LSA's LS Type is 0xa00a.


     LSA function code  LS Type  Description
     --------------------------------------------------------------------
     10                 0xa00a   Intra-Area-TE-LSA


   Link State ID of Intra-Area-TE-LSA should be the Interface ID of the
   link.


6. Security Considerations

   Security issues are not discussed in this memo.


7. Acknowledgements

   Thanks to Vishwas Manral, Kireeti Kompella and Alex Zinin for their
   comments.


8. Reference

   [RFC2702] RFC 2702, "Requirements for Traffic Engineering Over
             MPLS," D.  Awduche, J. Malcolm, J. Agogbua, M. O'Dell,
             and J. McManus, September 1999.

   [RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998.

   [RFC2740] R. Coltun, D. Ferguson, J.Moy, "OSPF for IPv6", RFC2740,
             December 1999.



Ishiguro                 Expires September 2003                 [Page 4]


Internet Draft  draft-ishiguro-ospf-ospfv3-traffic-02.txt     March 2003


   [OSPFV2-TE] Katz, D., Yeung, D., Kompella, K., "Traffic Engineering
               Extensions to OSPF",
               draft-katz-yeung-ospf-traffic-09.txt, work in progress.

   [OSPF-GMPLS] K. Kompella, Y. Rekhter, "OSPF Extensions in Support of
                Generalized MPLS",
                draft-ietf-ccamp-ospf-gmpls-extensions-09.txt, work in
                progress.

   [DIFFSERV-TE] F. L. Faucheur, J. Boyle,  K. Kompella, W. Townsend,
                 D. Skalecki, "Protocol extensions for support of
                 Diff-Serv-aware MPLS Traffic Engineering",
                 draft-ietf-tewg-diff-te-proto-02.txt, work in progress.


9. Author's Address

   Kunihiro Ishiguro
   IP Infusion Inc.
   111 W. St. John Street, Suite 910
   San Jose CA 95113
   e-mail: kunihiro@ipinfusion.com

   Toshiaki Takada
   IP Infusion Inc.
   111 W. St. John Street, Suite 910
   San Jose CA 95113
   e-mail: takada@ipinfusion.com























Ishiguro                 Expires September 2003                 [Page 5]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/