One document matched: draft-ietf-ospf-mt-ospfv3-01.txt
Differences from draft-ietf-ospf-mt-ospfv3-00.txt
Network Working Group Sina Mirtorabi
Internet Draft Abhay Roy
Expiration Date: September 2006 Cisco Systems
File name: draft-ietf-ospf-mt-ospfv3-01.txt
March 2006
Multi-topology routing in OSPFv3 (MT-OSPFv3)
draft-ietf-ospf-mt-ospfv3-01.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 5, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006).
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 March 2006
1. Motivation
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.
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.
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.
Mirtorabi, Roy [Page 2]
Internet Draft OSPFv3 MTR March 2006
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:
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 have a 16 bit Type and a 16 bit Length field followed by the
Mirtorabi, Roy [Page 3]
Internet Draft OSPFv3 MTR March 2006
TLV value. TLV 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
sub-TLVs are similar to TLVs with an additional 16 bit Total sub-TLV
length (in bytes) and a 16 bit reserved field. If the TLV has
multiple Values, total sub-TLV length allows to locate the next
Value, when there are variable number of sub-TLVs present.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Total sub-TLV length | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
OSPFv3 sub-TLV Format
The presence of sub-TLVs is indicated by a S-bit in the value field
of TLVs. If the S-bit is set, the format of sub-TLVs is as specified
above. If the S-bit is clear, no sub-TLVs are added.
For LSAs which carry a prefix, we define S-bit in PrefixOptions. Note
that S-bit in PrefixOptions is only defined in Extended LSAs.
0 1 2 3 4 5 6 7
+--+--+--+--+--+--+--+--+
|S | | | | P|MC|LA|NU|
+--+--+--+--+--+--+--+--+
The Prefix Options field
Mirtorabi, Roy [Page 4]
Internet Draft OSPFv3 MTR March 2006
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.
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.
Mirtorabi, Roy [Page 5]
Internet Draft OSPFv3 MTR March 2006
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.
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.
Mirtorabi, Roy [Page 6]
Internet Draft OSPFv3 MTR March 2006
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.
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 reserved value
The following MT range are pre-assigned:
MT#0 - MT#7 IPv6 Unicast
MT#8 - MT#15 IPv6 Multicast
MT#16 - MT#23 IPv4 Unicast
MT#24 - MT#31 IPv4 Multicast
MT#33 - MT#255 Reserved
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.
Mirtorabi, Roy [Page 7]
Internet Draft OSPFv3 MTR March 2006
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.
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 .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mirtorabi, Roy [Page 8]
Internet Draft OSPFv3 MTR March 2006
All fields are defined as in [OSPFv3].
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-Type | Reserved | Link-Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. sub-TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link-Type | Reserved | Link-Block Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. sub-TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Link-Block Length : Define the length of link block including
Link-Type, Reserved, Link-Block Length, fixed ID
fields 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 (Total
sub-TLV length indicates the next link description).
Mirtorabi, Roy [Page 9]
Internet Draft OSPFv3 MTR March 2006
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 |S| MT-ID metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID | 0 |S| MT-ID metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
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 March 2006
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 March 2006
20.3 Extended Inter-Area-Prefix-LSA
We define a new E-inter-area-prefix-LSA with LS type of 0xB003. It 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix-Block Length | PrefixLength | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix-Block Length | PrefixLength | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Mirtorabi, Roy [Page 12]
Internet Draft OSPFv3 MTR March 2006
Prefix-Block Length : Define the length of prefix block including
Prefix-Block Length, PrefixLength, Reserved
field, Address Prefix and TLVs.
All other fields are defined as in [OSPFv3].
We define an Inter Prefix Multi-Topology TLV (IPMT-TLV) below. This
TLV could further contain sub-TLVs.
E-inter-area-prefix-LSA must contain one or more prefix blocks and
each prefix block must contain the IPMT-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 (IPMT-TLV) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID | MT-ID metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixOptions | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID | MT-ID metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixOptions | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
20.4 Extended Inter-Area-Router-LSA
We define a new E-inter-area-router-LSA with LS type of 0xB004. 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].
Mirtorabi, Roy [Page 13]
Internet Draft OSPFv3 MTR March 2006
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. sub-TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. sub-TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Mirtorabi, Roy [Page 14]
Internet Draft OSPFv3 MTR March 2006
Destination Router ID: It is defined in [OSPFv3].
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
(Total sub-TLV length indicates the next destination router value).
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID | MT-ID metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
20.5 Extended AS-external-LSA
We define a new E-AS-external-LSA with LS type of 0xD005. This 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 15]
Internet Draft OSPFv3 MTR March 2006
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix-Block Length | PrefixLength | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix-Block Length | PrefixLength | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Prefix-Block Length : Define the length of prefix block including
Prefix-Block Length, PrefixLength, Reserved
field, Address Prefix and TLVs.
All other fields are defined as in [OSPFv3]
We define an External Prefix Multi-Topology TLV (EMT-TLV) below. This
EMT-TLV could further contain sub-TLVs.
E-AS-external-LSA must contain one or more prefix blocks and each
prefix block must contain the EMT-TLV.
Mirtorabi, Roy [Page 16]
Internet Draft OSPFv3 MTR March 2006
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-TLV) | 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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID | MT-ID metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |E|F|T| PrefixOptions| Referenced LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- Forwarding Address (Optional) -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Route Tag (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Referenced Link State ID (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Note that when the sub-TLV is present (S-bit set in the
PrefixOptions) the sub-TLV is placed after Forwarding address and
external route Tag if they are present.
Mirtorabi, Roy [Page 17]
Internet Draft OSPFv3 MTR March 2006
20.6 Extended Link-LSA
We define a new E-link-LSA with LS type of 0x9008. This 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]. This LSA has a fixed portion followed by
TLVs.
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.
Mirtorabi, Roy [Page 18]
Internet Draft OSPFv3 MTR March 2006
NH6-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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 extends link-LSA by defining TLV under each address prefix.
This TLV should only be present on multi-access links.
Mirtorabi, Roy [Page 19]
Internet Draft OSPFv3 MTR March 2006
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # prefixes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix-Block Length | PrefixLength | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix-Block Length | PrefixLength | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Prefix-Block Length : Define the length of prefix block including
Prefix-Block Length, PrefixLength, Reserved
field, Address Prefix and TLVs.
All other fields are defined as in [OSPFv3].
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 LMT-sTLV.
Mirtorabi, Roy [Page 20]
Internet Draft OSPFv3 MTR March 2006
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID | PrefixOptions | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
20.7 Extended Intra-Area-Prefix-LSA
We define a new E-intra-area-prefix-LSA with LS type of 0xB009. 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].
Mirtorabi, Roy [Page 21]
Internet Draft OSPFv3 MTR March 2006
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix-Block Length | PrefixLength | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Prefix-Block Length | PrefixLength | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
. .
. TLVs .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Prefix-Block Length : Define the length of prefix block including
Prefix-Block Length, PrefixLength, Reserved
field, Address Prefix and TLVs.
All other fields are defined as in [OSPFv3].
We define a Prefix Multi-Topology TLV (PMT-TLV) below. This TLV could
further contain sub-TLVs.
Mirtorabi, Roy [Page 22]
Internet Draft OSPFv3 MTR March 2006
E-intra-area-prefix-LSA must contain one or more prefix blocks and
each prefix block must contain the PMT-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 (PMT-TLV) | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID | PrefixOptions | MT-ID metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MT-ID | PrefixOptions | MT-ID metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
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. References
Normative References
[OSPFv3] R. Coltun, D. Ferguson and J. Moy, "OSPF for IPv6",
RFC 2740, December 1999.
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
Mirtorabi, Roy [Page 23]
Internet Draft OSPFv3 MTR March 2006
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
Cisco Systems Cisco Systems
170 W. Tasman Dr. 170 W. Tasman Dr.
San Jose, CA 95134, USA San Jose, CA 95134, USA
E-mail: sina@cisco.com E-mail: akr@cisco.com
Intellectual Property Statement
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.
Mirtorabi, Roy [Page 24]
Internet Draft OSPFv3 MTR March 2006
Disclaimer of Validity
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 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.
Copyright Statement
Copyright (C) The Internet Society (2004). 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.
Acknowledgment
Funding for the RFC Editor function is currently provided by the
Internet Society.
Mirtorabi, Roy [Page 25]
| PAFTECH AB 2003-2026 | 2026-04-23 16:37:25 |