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

Versions: 00 01 02 03

Network Working Group                                    Sina Mirtorabi
Internet Draft                                         Force10 Networks
Intended status: Standards Track                              Abhay Roy
Expiration Date: January 2008                             Cisco Systems
                                                              July 2007


                  Multi-topology routing in OSPFv3 (MT-OSPFv3)
                        draft-ietf-ospf-mt-ospfv3-03.txt




Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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.

   This Internet-Draft will expire on September 29, 2007.

Copyright Notice

   Copyright (C) The IETF Trust (2007).


Abstract

   This document describes an extensible mechanism to support multiple
   topologies (MT) in OSPFv3. These topologies can be used within the
   same address family in order to compute different paths for different
   classes of service, or belong to different address families allowing
   an integrated definition of address family with OSPFv3. The extension
   described in this document can further facilitate any future
   extensions of OSPFv3.


Mirtorabi, Roy                                                  [Page 1]

Internet Draft                  OSPFv3 MTR                     July 2007


1. Introduction

   Multi-topology routing as described in this document is similar in
   concept to M-ISIS [M-ISIS]. It is used to introduce an integrated
   definition of other address families in OSPFv3. Each address-family
   may also need to support multiple topologies, to compute different
   paths for different classes of service or in-band management network.

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].


2. Potential Solutions

   In order to support multiple topologies at least two different
   solutions are possible. We discuss them briefly below, and describe
   issues with each of them.


2.1 Using Different Instance IDs

   [INSTANCES] defines a range of Instance IDs for each address family.
   It is therefore possible to define multiple topologies by using
   different Instance IDs. However this approach is inefficient due to
   the overhead involved in having to manage multiple adjacencies,
   multiple link-state databases etc.


2.2 Using an integrated approach with existing LSAs

   Another solution would be to define multiple topologies as an
   integrated approach within each instance. This can be done by
   redefining an unused field in the link description of Router LSA and
   define it as a multi-topology identifier (MT-ID). We will have to
   generate N link descriptions for a link with N topologies configured
   on it. This seems wasteful as the link description is replicated
   N times, further we have some backward compatibility issues.

   Also, there is a need to identify prefixes carried for each topology,
   i.e. prefix-LSAs need to carry MT-IDs and there is no possibility to
   reuse the existing prefix-LSAs.


Mirtorabi, Roy                                                  [Page 2]

Internet Draft                  OSPFv3 MTR                     July 2007


3. Proposed Solution

   We propose to define new LSAs in order to achieve this. Not only does
   this allow an optimum definition of topologies within OSPFv3, it
   also does not have any backward compatibility issues as new LSAs will
   be ignored by old routers.

   The flexible encoding proposed for the new LSAs can also facilitate
   any future extension in OSPFv3.


4. MT Capability

   We define a Multi-topology capability bit in Options filed.


         0                   1                        2
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5  6  7  8  9  0  1  2  3
        -+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+--+--+--+--+
         | | | | | | | | | | | | | |MT|AF|* |* |DC| R| N|MC| E|V6|
        -+-+-+-+-+-+-+-+-+-+-+-+-+-+--+--+--+--+--+--+--+--+--+--+

                        The Options field


   MT-bit
     This bit is set when a router supports MT-OSPFv3 as specified
     in this memo.


5. T-bit in LS type

   We define a new T-bit (TLV based) in LS type field in order to extend
   the existing LSAs. This will define new LSA types homogeneously
   compared to the existing LSA types. The U-bit and the T-bit are set.

          0  1  2  3  4  5  6  7  8  9  0  1  2  3  4  5
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
         |U |S2|S1|T |       LSA Function Code           |
         +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+


  For the function codes defined in [OSPFv3] the LS types become:


Mirtorabi, Roy                                                  [Page 3]

Internet Draft                  OSPFv3 MTR                     July 2007


         LSA function code   LS Type   Description
         ----------------------------------------------------
         1                   0xB001    E-Router-LSA
         2                   0xB002    E-Network-LSA
         3                   0xB003    E-Inter-Area-Prefix-LSA
         4                   0xB004    E-Inter-Area-Router-LSA
         5                   0xD005    E-AS-External-LSA
         6                   0xB006    E-Group-membership-LSA
         7                   0xB007    E-Type-7-LSA
         8                   0x9008    E-Link-LSA
         9                   0xB009    E-Intra-Area-Prefix-LSA


6. OSPFv3 TLVs and sub-TLVs

   All the Extended LSAs have a flexible TLV format encoding. OSPFv3
   TLVs/sub-TLVs have a 16 bit Type and a 16 bit Length field followed
   by the TLV/sub-TLV value. The Length is set to the length of Value
   field in bytes. Any unknown TLV/sub-TLV should be ignored.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        TLV Type               |       TLV Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                         TLV Value                             .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                       OSPFv3 TLV Format


7. Default Topology

   In order to interact with non-MT capable routers we define default
   topology as the topology that is built by using the existing LSAs as
   specified in OSPFv3 [OSPFv3].

   We define MT topologies as topologies which are other than the
   Default Topology. A MT topology will be defined by using the new LSAs
   as specified in this memo.

   When all routers are MT capable, there is no need to generate
   existing LSAs as defined in [OSPFv3]. The new LSAs can be used even
   for Default Topology. A global configurable parameter
   RFC2740Compatibility (see Appendix A) is used to control the
   generation of existing or new LSAs.


Mirtorabi, Roy                                                  [Page 4]

Internet Draft                  OSPFv3 MTR                     July 2007


8. MT-ID Fields

   We define a 8 bit MT-ID field which is present in various LSA types.
   Each MT-ID is also accompanied with a MT-ID Metric field which
   carries a metric specific to one MT.

   When a MT capable router participates in Default Topology, depending
   on RFC2740Compatibility (see Appendix A) it will generate existing
   LSAs or extended LSAs for the Default Topology.

   MT-ID value 0 is reserved for carrying information about Default
   Topology in the new LSAs.


9. MT Control packet and IPv6 link local address

   IPv6 link local address is MT independent and is used for MT-OSPFv3
   control packets.


10. Forming adjacency in MT

   Each interface can be configured to belong to a set of topologies.
   A single adjacency will be formed even if the interface is configured
   to participate in multiple topologies.


11. Advertising MT topology

   When a router is configured with multiple topologies on a link, it
   advertises the list of MT-IDs and their corresponding metrics in
   E-router-LSA. When a MT-capable router participates in default
   topology, based on RFC2740Compatibility it may generate existing or
   Extended Router-LSAs.

   Network LSAs are common to all MT. The DR will announce an adjacency
   to all attached routers independently of their MT-ID value. When
   RFC2740Compatibility is disabled on DR (and all routers should be MT
   capable) E-network-LSA will be used instead of network-LSA. This
   allow a smooth migration to extended LSAs.


12. Advertising MT prefix

   When a MT-capable router participate in non-Default Topology, it
   generates extended prefix LSAs with MT-ID in which it participates.
   When a MT-capable router participates in default topology, based
   on RFC2740Compatibility it may generate existing or Extended
   prefix LSAs.


Mirtorabi, Roy                                                  [Page 5]

Internet Draft                  OSPFv3 MTR                     July 2007


13. Advertising intra-area-prefix-LSA on multi-access link

   On multi-access links, the DR is responsible to generate prefix-LSA
   on behalf of the LAN, this is done by considering the prefix
   advertised in link-LSAs.

   If RFC2740Compatibility is disabled the DR will generate Extended
   prefix-LSAs. If RFC2740Compatibility is enabled we select a
   Multi-Topology DR (MT-DR) which generates the E-intra-area-prefix-LSA
   on behalf of the LAN.

   MT-DR is elected by considering the highest Router ID among
   MT-capable routers (done by examining MT-bit of neighbors).

   The E-intra-area-prefix-LSA generated by the MT-DR will have the
   Referenced LS type set to 2, Referenced Link State ID set to DR's
   Router ID and Referenced Advertising Router set to DR's Router ID.
   Note that MT-DR's role is to just generate the
   E-intra-area-prefix-LSA whereas DR is responsible for network LSA
   generation and helping in flooding on the multi-access link.


14. MT Area Boundary

   Area boundaries for all topologies are the same but an interface can
   be configured to not participate in all topologies. This will make a
   router's B-bit setting topology independent whereas reachability to
   the ABR will be topology dependent.


15. MT SPF Computation

   When a link participates in a topology, it's MT-ID value is carried
   in extended Router-LSA. A separate SPF is computed for each topology
   by considering only the link/metric for the corresponding topology.

   Network LSAs are used by all topologies during the SPF computation.
   Nexthops computed during the MT SPF MUST belong to the same topology.

   Similarly when processing prefix-LSAs or external-LSAs, only prefixes
   which contain a valid MT Metric for that MT SPF are considered
   reachable in that topology.

   During SPF computation for the Default Topology, independently of
   RFC2740Compatibility value, extended LSA are used when present
   otherwise existing LSA are used. This allows a smooth transition
   across RFC2740Compatibility changes.


Mirtorabi, Roy                                                  [Page 6]

Internet Draft                  OSPFv3 MTR                     July 2007


16. Forwarding in MT

   Forwarding must make sure that only routes belonging to the single
   topology are used to forward the packet along its way from source to
   destination. Therefore user configuration MUST be consistently
   applied throughout the network so that an incoming packet be
   associated with the corresponding topology. It is outside of the
   scope of this document to consider different methods of associating
   an incoming packet to the corresponding topology routes.


17. MT-ID reserved value

  The following MT-ID values are defined:

            0      - Reserved for IPv6 unicast topology
            1      - Reserved for IPv4 in-band management purposes
            2      - Reserved for IPv4 unicast topology
            3      - Reserved for IPv6 multicast topology
            4      - Reserved for IPv4 multicast topology
           5-31    - Reserved for IETF consensus.
           32-255  - Reserved for development, experimental and
                     proprietary features [RFC3692].


18. IPv4 address family considerations

   OSPFv3 runs on the top of IPv6 and uses IPv6 link local addresses
   for OSPFv3 control packets and next hop calculations. Although IPV6
   link local addresses could be used as next hops for IPv4 address
   families, it is desirable to have IPv4 next hop addresses. For
   example, in IPv4 multicast having the nexthop address the same as
   the PIM neighbor address (IPv4 address) makes it easier to know to
   which upstream neighbor to send a PIM join when doing a RPF lookup
   for a source. It is also easier for troubleshooting purposes to have
   a next hop with the same semantics as the AF.

   In order to achieve this, the link's IPv4 address will be advertised
   in the E-link-LSA, see section 20.6.

   We call direct interface address (DIA) the address that is reachable
   directly via the link provided that a layer 3 to layer 2 mapping is
   available. Note that there is no explicit need for the IPv4 link
   addresses to be on the same subnet. An implementation should resolve
   layer 3 to layer 2 mappings via ARP or ND for a DIA even if the IPv4
   address is not on the same subnet as the router's interface IP
   address.


Mirtorabi, Roy                                                  [Page 7]

Internet Draft                  OSPFv3 MTR                     July 2007


19. Backward compatibility and interaction with non-MT routers

   An MT capable router will interact (in Default Topology) with non-MT
   capable routers by using the existing LSAs. MT information is carried
   in new LSAs which are ignored by non-MT routers therefore this
   document does not introduce any backward compatibility issues.

   When all routers are MT capable, RFC2740Compatibility can be set to
   disable and only extended LSAs are used for Default Topology.


20. Extended LSA Formats

20.1 Extended Router-LSA

   We define a new E-router-LSA with LS type equal to 0xB001. This LSA,
   extends router LSA by defining TLVs within the LSA payload. The LSA
   has a fixed portion followed by TLVs. Each TLV could further contains
   sub-TLVs.

   The processing and generation of this LSA is the same as for
   router-LSA defined in [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              |0|0|1|1|        1              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link State ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Advertising Router                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    LS sequence number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LS checksum            |             length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    0  |W|V|E|B|            Options                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                            TLVs                               .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   All fields are defined as in [OSPFv3].


Mirtorabi, Roy                                                  [Page 8]

Internet Draft                  OSPFv3 MTR                     July 2007


   We define a Link-description TLV (LD-TLV). This TLV extends the
   router-LSA payload by defining sub-TLVs within each link description.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          1 (LD-TLV)           |       TLV Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Link-Block Length       |       0       |   Link-Type   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Interface ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Neighbor Interface ID                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Neighbor Router ID                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                            sub-TLVs                           .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Link-Block Length       |       0       |   Link-Type   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                      Interface ID                             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                   Neighbor Interface ID                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Neighbor Router ID                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                            sub-TLVs                           .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                               |


   Link-Block Length : This field is used as a pointer to the next
                       link block. It defines the length of link block
                       including Link-Block Length, Link-Type field,
                       Interface ID, Neighbor Interface ID, Neighbor
                       Router ID and sub-TLVs

   All other fields are defined as in [OSPFv3].

   LD-TLV is the only top level TLV defined in this document. This TLV
   should not be repeated within an E-router-LSA fragment, instead
   multiple link descriptions are included within the LD-TLV.
   (Link-Block length indicates the next link description).


Mirtorabi, Roy                                                  [Page 9]

Internet Draft                  OSPFv3 MTR                     July 2007


   We define a Router Multi-Topology sub-TLV (RMT-sTLV) below. This
   sub-TLV could further contain sub-TLVs.

   E-router-LSA must contain the LD-TLV and each link description must
   contain the RMT-sTLV.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          1 (RMT-sTLV)         |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    MT-ID      |       0       |          MT-ID metric         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                            sub-TLVs                           .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   When a link participates in different topologies, it will include the
   RMT-sTLV with MT-IDs and MT-ID metrics for corresponding topologies.


20.2 Extended Network-LSA

   The network LSA does not contain any MT information as the DR is
   shared by all topologies therefore the existing network LSA can be
   used independently of the router participation in a MT.

   However we define an E-network-LSA in order to allow for any future
   extensions. The LS type is equal to 0xB002. This LSA extends
   network-LSA by defining TLVs within the LSA payload.

   The processing and generation of this LSA is the same as for
   network-LSA defined in [OSPFv3].


Mirtorabi, Roy                                                 [Page 10]

Internet Draft                  OSPFv3 MTR                     July 2007


    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              |0|0|1|1|         2             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link State ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Advertising Router                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    LS sequence number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LS checksum            |             length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                             TLVs                              .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   All fields are defined as in [OSPFv3].

   We define a Attached-Router TLV (AR-TLV). This TLV has similar
   contents as the network-LSA payload.

   E-network-LSA must contain AR-TLV.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           1 (AR-TLV)          |       TLV Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0        |                   Options                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Attached Router                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Attached Router                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                               |


   All fields are defined as in [OSPFv3].


Mirtorabi, Roy                                                 [Page 11]

Internet Draft                  OSPFv3 MTR                     July 2007


20.3 Extended Inter-Area-Prefix-LSA

   We define a new E-inter-area-prefix-LSA with LS type of 0xB003. This
   LSA, extends Inter-Area-Prefix-LSA by defining TLVs within the LSA
   payload. The LSA has a fixed portion followed by TLVs. Each TLV could
   further contains sub-TLVs. This LSA is originated by area border
   routers to describe routes to prefixes associated with a MT-ID that
   belong to other areas.


   An implementation could decide to advertise one or more prefixes
   within one E-inter-area-prefix-LSA.

   The processing and generation of this LSA is the same as for as
   inter-area-prefix-LSA as defined in [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              |0|0|1|1|           3           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link State ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Advertising Router                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    LS sequence number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LS checksum            |            length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                            TLVs                               .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   We define an Inter-area Prefix TLV (IAP-TLV). This TLV extends the
   Inter-Area-Prefix-LSA payload by defining sub-TLVs within each each
   prefix.


Mirtorabi, Roy                                                 [Page 12]

Internet Draft                  OSPFv3 MTR                     July 2007


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          1 (IAP-TLV)          |       TLV Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Prefix-Block Length         | PrefixLength  |       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Address Prefix                          |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                            sub-TLVs                           .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Prefix-Block Length         | PrefixLength  |      0        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Address Prefix                          |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                            sub-TLVs                           .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                               |



   Prefix-Block Length : This field is used as a pointer to the next
                         prefix block. It define the length of prefix
                         block including Prefix-Block Length,
                         PrefixLength, Address Prefix and sub-TLVs.

   All other fields are defined as in [OSPFv3].

   IAP-TLV is the only top level TLV defined by this document. This TLV
   should not be repeated within an E-Inter-area-prefix-LSA, instead
   multiple prefix values are included within the IAP-TLV. (Prefix-Block
   Length indicates the next prefix block).


   We define an Inter area Multi-Topology sub-TLV (IAMT-sTLV) below.
   This sub-TLV could further contain sub-TLVs.

   Each prefix block must contain an Inter area Multi-Topology sub-TLV
   (IAMT-sTLV).


Mirtorabi, Roy                                                 [Page 13]

Internet Draft                  OSPFv3 MTR                     July 2007


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        1 (IAMT-sTLV)          |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       MT-ID   |             MT-ID metric                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | PrefixOptions |                    0                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                            sub-TLVs                           .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


20.4 Extended Inter-Area-Router-LSA

   We define a new E-inter-area-router-LSA with LS type of 0xB004. This
   LSA, extends Inter-Area-Router-LSA by defining TLVs within the LSA
   payload. The LSA has a fixed portion followed by TLVs. Each TLV could
   further contains sub-TLVs. This LSA is originated by area border
   routers and describes routes to routers in other areas.

   An implementation could decide to advertise information about one or
   more routers within one E-inter-area-router-LSA.

   The processing and generation of this LSA is the same as for as
   inter-area-router-LSA as defined in [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              |0|0|1|1|          4            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link State ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Advertising Router                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    LS sequence number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LS checksum            |             length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   .                                                               .
   .                             TLVs                              .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Mirtorabi, Roy                                                 [Page 14]

Internet Draft                  OSPFv3 MTR                     July 2007


   All fields are defined as in [OSPFv3].

   We define a Dest-Router TLV (DR-TLV) below. This TLV extends the
   Inter-area-router-LSA payload by defining sub-TLVs within each
   Destination Router.

   E-inter-area-router-LSA must contain the DR-TLV.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        1 (DR-TLV)             |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Destination-RID-Block Length  |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0        |                  Options                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Destination Router ID                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                            sub-TLVs                           .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Destination-RID-Block Length  |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      0        |                  Options                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Destination Router ID                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                            sub-TLVs                           .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   Destination-RID-Block Length : This field is used as a pointer to the
                                  next Destination Router ID block. It
                                  defines the length of Destination
                                  Router ID block including
                                  Destination-RID-Block Length, Options,
                                  Destination Router ID and sub-TLVS.


   Destination Router ID: It is defined in [OSPFv3].


Mirtorabi, Roy                                                 [Page 15]

Internet Draft                  OSPFv3 MTR                     July 2007


   DR-TLV is the only top level TLV defined by this document. This TLV
   should not be repeated within an E-Inter-area-router-LSA, instead
   multiple destination router values are included within the DR-TLV
   (Destination-RID-Block Length indicates the next destination router
   block).

   We define an Inter Router Multi-Topology sub-TLV (IRMT-sTLV) below.

   DR-TLV must contain the IRMT-sTLV.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         1 (IRMT-sTLV)         |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      MT-ID    |             MT-ID metric                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                            sub-TLVs                           .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


20.5 Extended AS-external-LSA

   We define a new E-AS-external-LSA with LS type of 0xD005. This LSA
   extends AS-External-LSA by defining TLVs within the LSA payload.
   The LSA has a fixed portion followed by TLVs. Each TLV could further
   contains sub-TLVs. E-AS-External-LSA is originated by AS boundary
   routers, and describes destinations external to the AS associated
   to a MT-ID.

   An implementation could decide to advertise one or more prefixes
   within one E-AS-external-LSA.

   The processing and generation of this LSA is the same as for an
   AS-external-LSA as defined in [OSPFv3].


Mirtorabi, Roy                                                 [Page 16]

Internet Draft                  OSPFv3 MTR                     July 2007


    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              |0|1|0|1|           5           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link State ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Advertising Router                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    LS sequence number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                             TLVs                              .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



   We define an External Prefix TLV (EP-TLV). This TLV extends the
   External-Prefix-LSA payload by defining sub-TLVs within each
   prefix.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          1 (EP-TLV)           |       TLV Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Prefix-Block Length         | PrefixLength  |       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Address Prefix                          |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                            sub-TLVs                           .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Prefix-Block Length         | PrefixLength  |       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Address Prefix                          |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                            sub-TLVs                           .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                               |


Mirtorabi, Roy                                                 [Page 17]

Internet Draft                  OSPFv3 MTR                     July 2007


   Prefix-Block Length : This field is used as a pointer to the next
                         prefix block. It defines the length of prefix
                         block including Prefix-Block Length,
                         PrefixLength,  Address Prefix and sub-TLVs.

   All other fields are defined as in [OSPFv3].

   EP-TLV is the only top level TLV defined by this document. This TLV
   should not be repeated within an E-AS-External-LSA, instead multiple
   prefix are included within the EP-TLV. (Prefix-Block Length
   indicates the next prefix block).

   We define an External Multi-Topology sub-TLV (EMT-sTLV) below. This
   EMT-subTLV could further contain sub-TLVs.

   Each prefix block must contain an External Multi-Topology sub-TLV
   (EMT-sTLV).


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         1 (EMT-sTLV)          |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |      MT-ID    |             MT-ID metric                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         |E|F|T|  PrefixOptions|     Referenced LS Type        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-                Forwarding Address (Optional)                -+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                 External Route Tag (Optional)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Referenced Link State ID (Optional)             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                            sub-TLVs                           .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Mirtorabi, Roy                                                 [Page 18]

Internet Draft                  OSPFv3 MTR                     July 2007


20.6 Extended Link-LSA

   We define a new E-link-LSA with LS type of 0x9008.  This LSA
   extends Link-LSA by defining TLVs within the LSA payload. The LSA
   has a fixed portion followed by TLVs. Each TLV could further contains
   sub-TLVs. E-Link-LSA is generated for each link and carries each
   link's prefix in the corresponding topology. It also carries next hop
   IP information for the supported address families.

   The processing and generation of this LSA is the same as for Link-Lsa
   as defined in [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              |0|0|0|1|           8           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link State ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     Advertising Router                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                     LS sequence number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LS checksum            |             length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Rtr Pri    |                Options                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                            TLVs                               .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   We define the following three TLVs

      o IPv6 Next hop TLV (NH6-TLV)
      o IPv4 Next hop TLV (NH4-TLV)
      o Prefix Multi-topology TLV (PMT-TLV)


  Next hop TLVs carry IPv6/IPv4 information for next hop calculation.
  IPv6 next hop information MUST be a link local IPv6 address.
  Prefix-TLV carries router link's prefix on multi-access link. This
  information is used by DR in order to include those prefix in its
  E-intra-area prefix LSA.


  NH6-TLV has the following format:


Mirtorabi, Roy                                                 [Page 19]

Internet Draft                  OSPFv3 MTR                     July 2007


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           1 (NH6-TLV)         |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-                Link-local Interface Address                 -+
   |                                                               |
   +-                                                             -+
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

  This TLV MUST be present if the link participate in a MT belonging
  to IPv6 address family.


  NH4-TLV 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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           2 (NH4-TLV)         |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       IPv4 address                            |
   +---------------------------------------------------------------+


  This TLV MUST be present if the link participate in a MT belonging
  to IPv4 address family.


  PMT-TLV has the following format:

  PMT-TLV extends link-LSA by defining TLV under each address prefix.
  This TLV should only be present on multi-access links.


Mirtorabi, Roy                                                 [Page 20]

Internet Draft                  OSPFv3 MTR                     July 2007


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           3 (PMT-TLV)         |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Prefix-Block Length         | PrefixLength  |       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Address Prefix                          |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                           sub-TLVs                            .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Prefix-Block Length         | PrefixLength  |       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Address Prefix                          |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                           sub-TLVs                            .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   Prefix-Block Length : This field is used as a pointer to the next
                         prefix block. It defines the length of prefix
                         block including Prefix-Block Length,
                         PrefixLength Address Prefix and sub-TLVs.


   All other fields are defined as in [OSPFv3].

   PMT-TLV should not be repeated within an E-Link-LSA, instead
   multiple prefix are included within the PMT-TLV. (Prefix-Block Length
   indicates the next prefix block).

   We define a Link Multi-Topology sub-TLV (LMT-sTLV) below. This
   sub-TLV could further contain sub-TLVs.

   Each prefix block must contain the Link Multi-Topology sub-TLV
   (LMT-sTLV).


Mirtorabi, Roy                                                 [Page 21]

Internet Draft                  OSPFv3 MTR                     July 2007


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           1 (LMT-sTLV)         |           Length             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    MT-ID      | PrefixOptions |               0               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                            sub-TLVs                           .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+



20.7 Extended Intra-Area-Prefix-LSA

   We define a new E-intra-area-prefix-LSA with LS type of 0xB009. This
   LSA extends Intra-Area-Prefix-LSA by defining TLVs within the LSA
   payload. The LSA has a fixed portion followed by TLVs. Each TLV could
   further contains sub-TLVs. A router generates
   E-Intra-Area-Prefix-LSAs to advertise one or more prefixes associated
   with a topology.

   The processing and generation of this LSA is the same as for
   intra-area-prefix-LSA defined in [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              |0|0|1|1|         9             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Link State ID                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    Advertising Router                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                    LS sequence number                         |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |        LS checksum            |             length            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         # prefixes            |     Referenced LS type        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                  Referenced Link State ID                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               Referenced Advertising Router                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                             TLVs                              .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


Mirtorabi, Roy                                                 [Page 22]

Internet Draft                  OSPFv3 MTR                     July 2007


   We define an Intra-area-Prefix TLV (IA-TLV). This TLV extends the
   Intra-Area-Prefix-LSA payload by defining sub-TLVs within each each
   prefix.


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          1 (IA-TLV)           |       TLV Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Prefix-Block Length         | PrefixLength  |        0      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Address Prefix                          |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                           sub-TLVs                            .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Prefix-Block Length         | PrefixLength  |       0       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Address Prefix                          |
   |                             ...                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                          sub-TLVs                             .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                             ...                               |

   Prefix-Block Length : This field is used as a pointer to the next
                         prefix block. It Defines the length of prefix
                         block including Prefix-Block Length,
                         PrefixLength, Address Prefix and sub-TLVs.

   All other fields are defined as in [OSPFv3].

   IA-TLV is the only top level TLV defined by this document. This TLV
   should not be repeated within an E-Intra-area-prefix-LSA, instead
   multiple prefix values are included within the IA-TLV. (Prefix-Block
   Length indicates the next prefix block).


   We define an Intra-Area Multi-Topology sub-TLV (IMT-sTLV) below.
   This sub-TLV could further contain sub-TLVs.


   Each prefix block must contain Intra-Area Multi-Topology sub-TLV
   (IMT-STLV).


Mirtorabi, Roy                                                 [Page 23]

Internet Draft                  OSPFv3 MTR                     July 2007


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |         1 (IMT-sTLV)          |           Length              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    MT-ID      | PrefixOptions |         MT-ID metric          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                          sub-TLVs                             .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


21. Security Considerations

   The technique described in this document does not introduce any new
   security issues to the OSPFv3 protocol.


22. Acknowledgements

   The authors would like to thank Alex Zinin, Acee Lindem, Tom
   Henderson, Jeff Ahrenholz and Paul Wells for their comments on the
   document.


23. IANA Considerations
   IANA is requested to create a new registry, "OSPFv3 multi-topology ID
   values" with the assignment listed in Section 17 of this document
   and registration policies for future assignments.


24. References

   Normative References

   [OSPFv3] R. Coltun, D. Ferguson and J.  Moy,  "OSPF  for  IPv6",
            RFC 2740, December 1999.

   [RFC3692]  Narten, T., "Assigning Experimental and Testing
              Numbers Considered Useful", BCP 82, RFC 3692, January
              2004.

   [RFC-KEYWORDS] Bradner, S., "Key words for use in RFC's to Indicate
                  Requirement Levels", RFC 2119, March 1997.


Mirtorabi, Roy                                                 [Page 24]

Internet Draft                  OSPFv3 MTR                     July 2007


   Informative Reference

   [INSTANCES] Mirtorabi, S. et al, "Support of address families in
               OSPFv3", Internet Draft, work in progress

   [M-ISIS] T. Przygienda, N. Shen, N. Sheth, "M-ISIS: Multi Topology
            (MT) Routing in IS-IS", Internet Draft, work in progress


Appendix A. Global Parameter

   RFC2740Compatibility
     This parameter controls which LSAs are used for Default Topology.
     When set to "enabled", the Default Topology is described using
     existing LSAs [OSPFv3]. When set to "disabled" the Default Topology
     is described using Extended LSAs as specified in this memo. This
     parameter is set to "enabled" by default.


Authors' Addresses

   Sina Mirtorabi                           Abhay Roy
   Force10 Networks                         Cisco Systems
   350 Holger Way                           170 W. Tasman Dr.
   San Jose, CA 95134, USA                  San Jose, CA 95134, USA

   E-mail: sina@force10netwroks.com         E-mail: akr@cisco.com



Full Copyright Statement

   Copyright (C) The IETF Trust (2007).

   This document is subject to the rights, licenses and restrictions
   contained in BCP 78, and except as set forth therein, the authors
   retain all their rights.

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND
   THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS
   OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
   THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Mirtorabi, Roy                                                 [Page 25]

Internet Draft                  OSPFv3 MTR                     July 2007


Intellectual Property

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Acknowledgment

   Funding for the RFC Editor function is provided by the IETF
   Administrative Support Activity (IASA).





Mirtorabi, Roy                                                 [Page 26]


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