< draft-mirtorabi-ospf-tunnel-adjacency-00.txt   draft-mirtorabi-ospf-tunnel-adjacency-01.txt >
Network Working Group Sina Mirtorabi Network Working Group Sina Mirtorabi
Internet Draft Peter Psenak Internet Draft Peter Psenak
Document: draft-mirtorabi-ospf-tunnel-adjacency-00.txt Cisco Systems Document: draft-mirtorabi-ospf-tunnel-adjacency-01.txt Cisco Systems, Inc
Expiration Date: November 2003 May 2003 Expiration Date: June 2004
Acee Lindem
Redback Networks
December 2003
OSPF Tunnel Adjacency OSPF Tunnel Adjacency
draft-mirtorabi-ospf-tunnel-adjacency-00.txt draft-mirtorabi-ospf-tunnel-adjacency-01.txt
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet Drafts are working documents of the Internet Engineering Internet Drafts are working documents of the Internet Engineering
Task Force (IETF), its Areas, and its Working Groups. Note that other Task Force (IETF), its Areas, and its Working Groups. Note that other
groups may also distribute working documents as Internet Drafts. groups may also distribute working documents as Internet Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 38
draft" or "work in progress". draft" or "work in progress".
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
OSPF specification requires that intra-area paths are always The OSPF specification requires that intra-area paths are always
preferred over Inter-area paths regardless of the path's cost. This preferred over inter-area paths, regardless of the path's cost.
document describes a solution that will remedy this limitation In some situations this can lead to an inefficient usage of
without introducing any significant change to the current network resources. This document describes a solution that helps
specification. Further, this solution provides some other benefits to address this problem by creating adjacencies through backbone
such as automatic partition repair described in application section. area that belong to non-backbone areas.
1. Motivation 1. Motivation
There could be a requirement to prefer an Inter-area path over an There could be a requirement to prefer an inter-area path over an
intra-area path, for example in order to utilize the high bandwidth intra-area path. For example, in order to utilize a high bandwidth
backbone path to transit the intra-area traffic from a non-backbone backbone path to transit the intra-area traffic from a non-backbone
area. The current OSPF specification does not provide any generic area. The current OSPF specification does not provide any generic
mechanism to be able to achieve this. In some situations Virtual mechanism to achieve this. In some situations, Virtual
Link (VL) can help, however there are some restrictions applied to Links (VLs) can help. However, there are some restrictions associated
VL: with VLs:
a) Transit area needs to be a non-backbone regular area a) Transit area must be a non-backbone regular area
b) VL prevents summarization of backbone prefixes into transit b) VLs prevent summarization of backbone prefixes into their
area associated transit area
c) VL cannot be configured through Stub or NSSA [2] areas c) VLs cannot be configured through Stub or NSSA [2] areas
2. Proposed Solution 2. Proposed Solution
The Tunnel Adjacency (TA) proposal uses a similar concept as The Tunnel Adjacency (TA) proposal uses a concept similar to
virtual link, e.g. forming an (possibly multihop) adjacency between virtual links by forming an adjacency (possibly multihop) between
two ABRs through the transit area, however TA can be configured for two ABRs through a transit area. However, TAs can be configured for
any area and the transit area can also be any area. any non-backbone area with the backbone as the transit area.
Tunnel adjacency's concept is close to VL in the way of Tunnel Adjacencies operate similar to VLs in adjacency establishment,
establishing an adjacency, sending unicast OSPF packets and sending unicast OSPF packets, and datbase synchronization. Data packet
synchronizing the database over it. Data packet forwarding between forwarding between the endpoint ABRs is different from VLs in that
the two ABRs is different from a VL in that the packets are tunneled the packets are tunneled if the TA's path spans multiple hops. This
if the TA path spans multiple hops. This removes the requirement removes the requirement for routers internal to the transit area to
for routers internal to the transit area to have the TA area's have the TA area's unsummarised intra-area routes. The rest of this
unsummarised intra-area routes. The rest of this document describes document describes the TA specification.
TA specification.
3. Bringing up the tunnel adjacency 3. Bringing up the tunnel adjacency
TA is configured between two ABRs attached to the same OSPF area. TAs are configured between two ABRs attached to the backbone.
This area is called Tunnel-adjacency Transit Area (TTA). Similar to Similiar to virtual links, TAs are identified by the Router ID of the
Virtual Link, TA is identified by the Router ID of the other
endpoint. Once a tunnel adjacency for a given area is configured and endpoint. Once a tunnel adjacency for a given area is configured and
an intra-area path exists between the two ABRs through the TTA, the an intra-area path exists between the two ABRs through the backbone
router can start forming adjacency with the remote neighbor by an adjacency can be formed as specified in OSPF [1].
sending unicast Hellos and synchronizing the database over TA as
specified in OSPF [1].
The interface MTU should be set to 0 in Database Description The interface MTU should be set to 0 in Database Description
Packets sent over the TA as it is done with virtual links. TA could packets sent over TAs as is done with virtual links. TAs can
be configured as a Demand Circuit (DC) in order to reduce Hello be configured as a Demand Circuits (DC) in order to reduce Hello
exchange and periodic LSA flooding. exchange and periodic LSA flooding.
4. Tunnel adjacency encapsulation 4. Tunnel adjacency encapsulation
User traffic routed based on the presence of the TA will be User traffic routed based on the presence of the TA will be
encapsulated on the TA endpoints in the following way: encapsulated on the TA endpoints in the following way:
a) If both ends of the TA are directly connected to the same a) If both ends of the TA are directly connected to the same
network and the best intra-area path to the TA endpoint in the network and the best intra-area path over the backbone is via
TTA is over this direct network connection, NO special this direct network connection, no additional encapsulation is
encapsulation is needed. needed.
b) Otherwise the traffic is further encapsulated (tunneled) and b) Otherwise, the traffic is further encapsulated (tunneled) and
sent directly to the TA endpoint. The encapsulation type is sent directly to the TA endpoint. The encapsulation type is
left to the implementation and different encapsulation types left to the implementation and different encapsulation types
could be specified through configuration. However, in order to could be specified through configuration. However, in order
have interoperability between vendors all implementation should to have interoperability between vendors all implementations
support GRE encapsulation. should support GRE encapsulation [3].
5. Advertising tunnel adjacency 5. Advertising tunnel adjacency
TA is announced as an unnumbered point-to-point link. Once the TAs are announced as unnumbered point-to-point links. Once a
router's TA reaches the FULL state it will be added as a link type 1 router's TA reaches the FULL state a type 1 link will be added to
to the Router LSA with: the Router LSA with:
Link ID = remote's Router ID Link ID = Remote's Router ID
Link Data = router's own IP address associated with TA Link Data = Router's own IP address associated with TA
Cost = intra area cost to the TA endpoint in the TTA or the Cost = Intra-area cost to the TA endpoint via the backbone area
configured cost or the configured cost
The IP address specified in the link data is computed during the The IP address specified in the link data is computed during the
routing table build process for the TTA. routing table build process for the backbone.
6. Tunnel adjacency interface data structure 6. Tunnel adjacency interface data structure
An OSPF interface data structure is created for each configured The TA interface data structure is the same as specified
tunnel adjacency. The cost of the TA is configurable allowing a in section 9 of OSPF [1]. An OSPF interface data structure is
traffic path to be selected independent of the intra-area path created for each configured tunnel adjacency. The cost of the TA
cost. The default cost is equal to the intra-area cost to reach the is configurable allowing a traffic path to be selected independent
remote TA's neighbor in the TTA. of the intra-area path cost. The default cost is equal to the
intra-area cost to reach the TA endpoint through the backbone.
TA is considered as unnumbered point-to-point interface. Topologically, a TA is identical to an unnumbered point-to-point
interface.
7. Tunnel adjacency interface FSM 7. Tunnel adjacency interface FSM
TA Interface FSM is the same as specified in OSPF [1]. The TA Interface FSM is the same as specified in section 9.3
The InterfaceUp event for TA interfaces is generated once the of OSPF [1]. The InterfaceUp event for TA interfaces is generated
intra-area path to the remote end of the TA becomes reachable once the remote end of the TA becomes reachable through the backbone
through the TTA. via an intra-area path.
InterfaceDown event is generated for TA when the intra-area Similiarly, the InterfaceDown event is generated for TA interfaces
path to the remote end of the TA is lost in TTA. when the remote end of the TA is no longer reachable through the
backbone via an intra-area path.
8. Tunnel adjacency neighbor data structure 8. Tunnel adjacency neighbor data structure
TA neighbor data structure is identical to the neighbor data The TA neighbor data structure is identical to the neighbor data
structure for standard OSPF adjacencies as specified in OSPF [1]. structure for standard OSPF adjacencies as specified in section 10
of OSPF [1].
9. Tunnel adjacency neighbor FSM 9. Tunnel adjacency neighbor FSM
TA neighbor FSM is identical to the neighbor FSM for standard
OSPF point-to-point adjacencies. The TA neighbor FSM is identical to the neighbor FSM for a standard
OSPF point-to-point adjacency as specified in section 10.3
of OSPF [1].
10. Tunnel adjacency OSPF control packet processing 10. Tunnel adjacency OSPF control packet processing
OSPF control packet processing is specified in OSPF [1] section 8. OSPF control packet processing is specified in OSPF [1] section 8.
This section is modified as follow : This section is modified as follow:
[...] [...]
The IP source address should be set to the IP address of the The IP source address should be set to the IP address of the
sending interface. Interfaces to unnumbered point-to-point networks sending interface. Interfaces to unnumbered point-to-point networks
have no associated IP address. On these interfaces, the IP source have no associated IP address. On these interfaces, the IP source
should be set to any of the other IP addresses belonging to the should be set to any of the other IP addresses belonging to the
router. For this reason, there must be at least one IP address router. For this reason, there must be at least one IP address
assigned to the router. Note that, for most purposes, virtual links assigned to the router. Note that, for most purposes, virtual links
and tunnel adjacency act precisely the same as unnumbered and tunnel adjacency act precisely the same as unnumbered
point-to-point networks. point-to-point networks.
However, each virtual link or tunnel adjacency does have an IP However, each virtual link or tunnel adjacency does have an IP
interface address belonging to transit area or TTA (discovered interface address belonging to a transit area or backbone (discovered
during the routing table build process) which is used as the IP during the routing table build process) which is used as the IP
source when sending packets over the virtual link or tunnel source when sending packets over the virtual link or tunnel
adjacency. If there is not at least one IP address belonging to adjacency. If there is not at least one IP address belonging to
Transit area or TTA and the virtual link or TA is configured, a Transit area or the backbone and a virtual link or TA is configured,
router could advertise any of its attached IP address as a stub link a router could advertise any of its attached IP address as a stub link
(Link ID set to the router's own IP interface address, Link Data set (Link ID set to the router's own IP interface address, Link Data set
to the mask 0xffffffff) to the transit area. to the mask 0xffffffff) to the transit area.
[...] [...]
Receiving protocol packets as described in 8.2 is changed as follow: Receiving protocol packets as described in 8.2 is changed as follow:
Next, the OSPF packet header is verified. The fields specified in Next, the OSPF packet header is verified. The fields specified in
the header must match those configured for the receiving interface. the header must match those configured for the receiving interface.
If they do not, the packet should be discarded: If they do not, the packet should be discarded:
o The version number field must specify protocol version 2. o The version number field must specify protocol version 2.
o The Area ID found in the OSPF header must be verified. If all of o The Area ID found in the OSPF header must be verified. If all of
the following cases fail, the packet should be discarded. the following cases fail, the packet should be discarded.
The Area ID specified in the header must either: The Area ID specified in the header must either:
(1) Match the Area ID of the receiving interface. In this case, (1) Match the Area ID of the receiving interface. In this case,
the packet has been sent over a single hop. Therefore, the packet has been sent over a single hop. Therefore, the
the packet's IP source address is required to be on the packet's IP source address is required to be on the same
same network as the receiving interface. This can be verified network as the receiving interface. This can be verified by
by comparing the packet's IP source address to the interface's comparing the packet's IP source address to the interface's
IP address, after masking both addresses with the interface IP address, after masking both addresses with the interface
mask. This comparison should not be performed on mask. This comparison should not be performed on point-to-point
point-to-point networks. On point-to-point networks, the networks. On point-to-point networks, the interface addresses
interface addresses of each end of the link are assigned of each end of the link are assigned independently, if they
independently, if they are assigned at all. are assigned at all.
(2) Indicate a non-backbone area. In this case, the packet has (2) Indicate a non-backbone area. In this case, the packet has
been sent over a tunnel adjacency. The receiving router must been sent over a tunnel adjacency. The receiving router must
be an area border router, and the Router ID specified in the be an area border router, and the Router ID specified in the
packet (the source router) must be the other end of a packet (the source router) must be the other end of a
configured tunnel adjacency. The receiving interface must configured tunnel adjacency. The receiving interface must
also attach to the TTA. If all of these checks succeed, the also attach to the backbone. If all of these checks succeed,
packet is accepted and is from now on associated with the the packet is accepted and is from now on associated with
tunnel adjacency for that area. the tunnel adjacency for that area.
(3) Indicate the backbone. In this case, the packet has been sent
over a virtual link or tunnel adjacency. The receiving router
must be an area border router, and the Router ID specified in
the packet (the source router) must be the other end of a
configured virtual link or tunnel adjacency. The receiving
interface must also attach to the virtual link's configured
transit area or tunnel adjacency's configured TTA. If all
of these checks succeed, the packet is accepted and is from
now on associated with the virtual link or tunnel adjacency.
[Note if there is a match for both a VL and TA then this is a (3) Indicate the backbone. In this case, the packet has been
configuration error that should be handled at the configuration sent over a virtual link. The receiving router must be an
level.] area border router, and the Router ID specified in the
packet (the source router) must be the other end of a
configured virtual link. The receiving interface must
also attach to the virtual link's configured Transit area.
If all of these checks succeed, the packet is accepted
and is from now on associated with the virtual link
(and the backbone area).
o Packets whose IP destination is AllDRouters should only be o Packets whose IP destination is AllDRouters should only be
accepted if the state of the receiving interface is DR or accepted if the state of the receiving interface is DR or
Backup (see Section 9.1). Backup (see Section 9.1).
[...] [...]
11. Tunnel adjacency next hop calculation 11. Tunnel adjacency next hop calculation
The next-hop to reach the TA endpoint is equal to the next-hop The next-hop to reach the TA endpoint is equal to the next-hop
associated with the TA endpoint inside the TTA. associated with the TA endpoint via the backbone area.
Data packet forwarding between the two ABRs is different from a Data packet forwarding between the two ABRs is different from a
VL in that the packets are tunneled if the TA path spans multiple VL in that the packets are tunneled if the TA path spans multiple
hops. This removes the requirement for routers internal to the hops. This removes the requirement for routers internal to the
transit area to have the TA area's unsummarised intra-area routes. backbone area to have the TA area's unsummarised intra-area routes.
12. Virtual link - tunnel adjacency comparison 12. Virtual link - tunnel adjacency comparison
Virtual link has the following limitations: Virtual links are part of area 0 and must transit through a regular
non-backbone area and are configured to avoid backbone partitioning.
1) The link should belong to a non-backbone area Conversely, tunnel adjacencies can be part of any type non-backbone
area and use the backbone as a transit area. Hence, TAs complement
2) Backbone area route cannot be summarized into the Transit area virtual links and address the following requirements (refer to the
applications section for more information):
3) VL can not be configured through Stub or NSSA area
Tunnel adjacency remedies all the above limitations. Further it
will allow:
a) The cost of TA is configurable allowing a traffic path to be a) Preference of a high speed backbone area link for non-backbone
selected independent of the intra-area path cost, making it traffic.
ideal to force a traffic path.
b) It can be used as an on demand partition repair. In this b) On-demand (automatic) partition repair for non-backbone areas.
application, the TA will be established only if the two end of
TA are not reachable over a given area (see application
section).
c) Multiple TAs could be configured over a TTA, each (TA) c) Multiple TAs could be configured over a backbone path, each (TA)
belonging to a different area in order to provide an intra area belonging to a different area in order to provide an intra-area
path for each area therefore saving cost of adding additional path for each area and saving the cost of an additional link.
links (see application section).
Tunnel Adjacency can be considered as a generalization of Virtual An additional advantage is the cost of TA is configurable allowing
Link. a traffic path to be selected independent of the intra-area path
cost. This allows an alternate traffic path to be forced.
13. Applications 13. Applications
In this section we give a few examples in which TA can be used. In this section we give a few examples of how TAs can be used.
13.1 Prefer Inter-area Path over intra-area Path 13.1 Prefer Inter-area Path over intra-area Path
It is a common example that users would like to prefer the high It is a common requirement that users would like to prefer the high
bandwidth part of the backbone for traffic that can be strictly bandwidth part of the backbone for traffic that can be strictly
routed inside the non-backbone area. routed inside the non-backbone area.
Consider the following topology: Consider the following topology:
R1-------backbone------R2 R1-------backbone------R2
| | | |
area 1 area 1 area 1 area 1
| | | |
R3--------area 1--------R4 R3--------area 1--------R4
Fig.1 Fig.1
The backbone link between R1 and R2 is a high speed link and could be The backbone link between R1 and R2 is a high speed link and could
used to forward part of the traffic of area 1 between R1 and R2. be used to forward part of the area 1's traffic between R1 and R2.
In the current OSPF specification, intra-area path are preferred over In the current OSPF specification, intra-area paths are preferred
inter-area path. As a result R1 will always route traffic to R4 over inter-area paths. As a result, R1 will always route traffic
through area 1 involving lower speed links. Even to reach networks to R4 through area 1 over the lower speed links. Even to reach
connected to R2 that belong to area 1, R1 will use the intra-area networks connected to R2 that belong to area 1, R1 will use the
path over area 1. intra-area path over area 1.
By configuring a TA between R1 and R2 a p2p link will be advertised
into area 1 making the TA visible as a topological part of area 1 and
by associating a low cost with TA, R1 will now compare two intra-area
path and choose the one with lower cost.
Note that the above scenario can not be solved by VL since the link
between R1 and R2 belongs to the backbone area and it is not
desirable to move this backbone link into a non-backbone area.
It should also be noted that the connection between R1 and R2 in the
backbone area could be multi-hop away, therefore there is no one hop
limitation for TA.
13.2 On demand partition avoidance for the backbone
It can be desirable to not have a virtual link unless the backbone
is partitioned, because the backbone's configured ranges are ignored
when originating summary-LSA into a transit area. On demand partition
repair requires checking to see if the two ends of TA are reachable
through the backbone area before starting to form the adjacency.
When a TA is configured between the two ABRs a configuration option
(automatic) will be used to not start sending Hello unless the other
ABR is not reachable over the backbone area. Further, once the on
demand adjacency is configured the check for ABR status is ignored
during formation of the TA adjacency, because ABR may lose its
backbone link and lose its ABR status, but the TA still needs to be
established.
The cost of on-demand TA should automatically be set to maximum
cost LSInfinity (16-bit value 0xFFFF). The reason to set the cost of
TA to 0xFFFF in this case is to make it easier to detect that the
partitioned area healed. During the SPF only the shortest path to
the remote end of the TA is discovered and if the shortest path is
via the TA itself, there is no simple way to find out that an
alternative intra-area path to the remote end of the TA, other than
over TA itself, exist. Setting the metric of TA to 0xFFFF makes
this task easier.
R1-------area 1--------R2 By configuring a TA between R1 and R2, a P2P link will be advertised
| | into area 1 making the TA a topological part of area 1 with a lower
backbone backbone cost than than the low speed links.
| |
R3--------backbone-----R4
Fig.2 Note that the above scenario can not be solved using a VL since the
link between R1 and R2 belongs to the backbone area and it is not
desirable to move this backbone link in a non-backbone area.
In the above topology in order to have an on demand VL for the It should also be noted that the connection between R1 and R2 in
backbone, an on demand TA can be configured between R1 and R2 for the backbone area could be multiple hops away. In other words,
backbone through area 1. Should the backbone be partitioned, R1/R2 TAs are not limited to directly connected topologies.
are not reachable over the backbone and they start forming adjacency
through area 1 for the backbone.
13.3 On demand partition avoidance for summarized non-backbone area 13.2 On-demand partition avoidance for summarized non-backbone area
In general when a non-backbone area is partitioned there is no In general when a non-backbone area is partitioned there is no
need for partition repair as an intra-area route will be replaced by need for partition repair as intra-area routes will be replaced
an Inter-area route for a segmented area. However this is not true by inter-area routes for the partiationed area. However, this is
any more if the area is summarized into the backbone. Consider the not true if the area is summarized into the backbone. Consider
following topology: the following topology:
R1-------backbone------R2 R1-------backbone------R2
| | | |
area 1 area 1 area 1 area 1
| | | |
R3--------area 1--------R4 R3--------area 1--------R4
Fig.3 Fig.3
R1 and R2 are summarizing area 1 into the backbone area. when R1 and R2 are summarizing area 1 into the backbone area. When area
area becomes partitioned, for example when R3-R4 link is broken, R1 1 becomes partitioned due the R3-R4 going down, R1 and R2 continue
and R2 still continue to summarize area 1 into the backbone area. to summarize area 1 into the backbone area. This can lead to
This can lead to blackholing of the traffic. The reason is that blackholing of the traffic. The reason is that after the area
after the area partitioning, R1 or R2 will only have knowledge of partitioning, R1 or R2 will only have knowledge of their attached
their attached partitioned area. When R1 or R2 receives a packet area partitions. When R1 or R2 receives a packet that does not
that does not belong to it's attached partitioned area (as a result belong to its attached partitioned area (as a result of advertising
of advertising a summary) the packet will be discarded. a summary) the packet will be discarded.
Note that R1 and R2 will install a discard route for the Note that R1 and R2 will install a discard route for the configured
configured summary range. If the destination is not found in the summary range. If the destination doesn't match an intra-area
attached area the packet is discarded following the discard route route in R1 or R2 area partition, the destination will match on
entry in the routing table. the less specific discard route.
By configuring an on demand TA for area 1 through the backbone, By configuring an on-demand TA for area 1 through the backbone,
R1/R2 will establish an adjacency should area 1 becomes partitioned, R1 and R2 will establish an adjacency if area 1 becomes
that is when R1/R2 is not reachable over area 1. partitioned.
Note that the cost of on-demand TA should be set to maximum cost When a TA is configured between the two ABRs, a configuration option
LSInfinity (16-bit value 0xFFFF). (automatic) will be used to not start sending Hellos unless the other
ABR is not reachable via area 1.
13.4 Saving additional link between ABRs in a Hub and Spoke environment The cost of on-demand TA should automatically be set to maximum
cost LSInfinity (16-bit value 0xFFFF). The reason to set the cost of
TA to 0xFFFF is to make it easier to detect that the area is no longer
partitioned. During the SPF, only the shortest path to the remote end
of the TA is discovered and making the TA cost the maximum reachable
cost will allow partition repair to be detected as a natural side
effect of the intra-area SPF calculation.
Consider the typical Hub and Spoke topology in figure 4. 13.3 Saving additional link between ABRs in a Hub and Spoke environment
Consider the typical hub and spoke topology in figure 4.
R1---BB--R2 R1---BB--R2
| \ / | | \ / |
| \ / | | \ / |
| \/ | | \/ |
| /\ | | /\ |
| / \ | | / \ |
Spoke1 Spoke2 Spoke1 Spoke2
Fig.4 Fig.4
Only two Spokes are represented in figure 4, but in general we may Only two spokes are represented in figure 4, but in general we may
have N spokes similar to Spoke1. have N spokes similar to Spoke1.
R1 and R2 are ABRs and can be multiple hops away over the backbone R1 and R2 are ABRs and can be multiple hops away over the backbone
area (BB).Further, the ABRs are summarizing IP prefixes from all the area (BB). Further, the ABRs are summarizing IP prefixes from all
attached areas into the backbone. the attached areas into the backbone.
Case 1: Spoke1 and Spoke2 are in different area Case 1: Spoke1 and Spoke2 are in different area
----------------------------------------------- -----------------------------------------------
Since both R1 and R2 are summarizing, there is a need for a link Since both R1 and R2 are summarizing, there is a need for a link
between R1 and R2 in each connected area. This is to guarantee an between R1 and R2 in each connected area. This is to guarantee an
alternative path when the link between a spoke and Hub becomes alternative path when the link between a spoke and hub becomes
unavailable. unavailable.
For example imagine a network X advertised by Spoke1 and For example, imagine a network X advertised by Spoke1 and summarized
summarized by both R1 and R2. Later the link between R1 and Spoke1 by both R1 and R2. Later the link between R1 and Spoke1 goes down.
goes down. When a packet arrives at R1 to be forwarded to Spoke1, R1 When a packet arrives at R1 to be forwarded to Spoke1, R1 cannot send
cannot send the packet to Spoke1 since the link is not available and the packet to Spoke1 since the link is not available.
R1 by summarizing may have installed a discard route for summarized Since R1 is summarizing this route it may have installed a discard
range (here we assume the range is still 'active', as there may be route for summarized range (here we assume the range is still 'active',
other spokes in the same area as Spoke1, single attached to R1 and as there may be other spokes in the same area as Spoke1 that are still
advertising prefixes that falls in the same range as X), so R1 will attached to R1 and advertising prefixes that fall in the same range as X).
not use an inter-area path over R2. A link between R1 and R2, Hence, R1 will not use an inter-area path over R2. A link between R1
inside the same area as the link between R1 and Spoke1 is, would and R2 inside the same area as the link between R1 and Spoke1 would
prevent this problem. prevent this problem.
Case 2: Spoke1 and Spoke2 are in the same area Case 2: Spoke1 and Spoke2 are in the same area
---------------------------------------------- ----------------------------------------------
Link between R1 and Spoke1 is broken. The path from R1 to Spoke1 is Link between R1 and Spoke1 is broken. The path from R1 to Spoke1 is
R1-Spoke2-R2-Spoke1 instead of R1-R2-Spoke1. R1-Spoke2-R2-Spoke1 instead of R1-R2-Spoke1.
In general, for N areas being attached to the Hub routers, there In general, for N areas being attached to the hub routers, there is
is a need for N links between Hub routers. Multiple TA could be used a need for N links between hub routers. Multiple TAs could be used
through the backbone between the Hub routers to avoid using multiple through the backbone between the hub routers to avoid using multiple
physical links (each belonging to a different non-backbone area) physical links between ABRs (each belonging to a different
between ABRs. non-backbone area)
14. Tunnel adjacency parameters 14. Tunnel adjacency parameters
Tunnel adjacency can be configured between area border routers Tunnel adjacencies can be configured in a non-backbone areas between
having interfaces to a common area and it can belong to any area. area border routers having at least one backbone conection.
The tunnel adjacency appears as an unnumbered point-to-point link in
the graph for the configured area. Tunnel adjacency must be
configured on both ends.
A tunnel adjacency is defined by the following configurable A tunnel adjacency is defined by the following configurable
parameters: parameters:
o The Router ID of the Tunnel adjacency's other endpoint. o The Router ID of the Tunnel adjacency's endpoint.
o The TTA area through which the tunnel adjacency runs. o The area where the tunnel adjacency resides.
o The area to which the tunnel adjacency belong. Optionally, the following parameters are configurable:
Optionally the following configurable parameters can be set: o The cost of the tunnel adjacency which will override
intra-area cost between the two TA endpoints.
o cost of the tunnel adjacency which will overwrite the o The encapsulation type to be used when the two TA endpoints
intra-area cost between the two endpoint of the TA. are not directly connected. The default is GRE.
o Encapsulation type used between the two endpoint of the TA. o The 'automatic' option used for on on-demand partition repair.
o 'Automatic' option used for on demand partition repair. 15. Tunnel adjacency in OSPFv3
15. Compatibility issues All mechanisms described in this document for OSPFv2 applies also to
OSPFv3 [4] with the following exceptions:
o The IPv6 interface address of a tunnel adjacency must be an IPv6
address having a global scope, instead of the link-local addresses
used by other interface types. This address is used as the IPv6
source for OSPF protocol packets sent over the tunnel adjacency.
o Likewise, the tunnel adjacency neighbor's IPv6 address is an IPv6
address with global scope.
o Like all other IPv6 OSPF interfaces, tunnel adjacency are assigned
unique (within the router) Interface IDs. These are advertised in
Hellos sent over the tunnel adjacency and specified for links in
the router's router-LSAs.
16. Compatibility issues
All mechanisms described in this document are backward-compatible All mechanisms described in this document are backward-compatible
with standard OSPF implementations. with standard OSPF implementations.
16. Security 17. Security
Tunnel adjacency specified in this document does not raise any Tunnel adjacencies as specified in this document do not raise any
security issues that are not already covered in [1]. security issues that are not already covered in [1].
17. Acknowledgments 18. Acknowledgments
Authors would like to thank Abhay Roy, Liem Nguyen, Acee Lindem Authors would like to thank Abhay Roy, Liem Nguyen, Pat Murphy,
and Pat Murphy for their comments on the document. and Alex Zinin for their comments on the document.
18. Reference 19. Reference
[1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [1] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[2] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", [2] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option",
RFC 3101, January 2003. RFC 3101, January 2003.
19. Authors' address [3] D. Farinacci, T. Li, S. Hanks, D. Meyer and P. Traina,
"Generic Routing Encapsulation (GRE), RFC 2784, March 2000.
[4] R. Coltun, D. Ferguson and J. Moy, "OSPF for IPv6",
RFC 2740, December 1999.
20. Authors' address
Sina Mirtorabi Sina Mirtorabi
Cisco Systems Cisco Systems
225 West Tasman drive 225 West Tasman drive
San Jose, CA 95134 San Jose, CA 95134
E-mail: sina@cisco.com E-mail: sina@cisco.com
Peter Psenak Peter Psenak
Cisco Systems Cisco Systems
Parc Pegasus, Parc Pegasus,
De Kleetlaan 6A De Kleetlaan 6A
1831 Diegem 1831 Diegem
Belgium Belgium
E-mail: ppsenak@cisco.com E-mail: ppsenak@cisco.com
Acee Lindem
Redback Networks
102 Carric Bend Court
Cary, NC 27519
Email: acee@redback.com
 End of changes. 75 change blocks. 
247 lines changed or deleted 229 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/