Network Working Group P. Pillay-Esnault
Internet-Draft M. Barnes
Intended status: Standards Track P. Wells
Expires: September 2, 2010 Cisco Systems
March 1, 2010
OSPFv2 No Transit Capability
draft-pillay-esnault-ospf-rbit-00
Abstract
Open Shortest Path First for IPv6 incorporates an R-bit in the router
Link State Advertisement that controls whether or not other routers
will compute transit paths through that node when they perform their
Shortest Path First computation. This is a very useful feature of
the protocol which is currently unavailable in Open Shortest Path
First Version 2.
This document extends the Open Shortest Path First Version 2
specification by adding a similar capability in a way that can safely
coexist with implementations lacking this feature.
Status of This Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and 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 2, 2010.
Copyright Notice
Pillay-Esnault, et al. Expires September 2, 2010 [Page 1]
Internet-Draft OSPFv2 No Transit Capability March 2010
Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
described in the BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Specification of Requirements . . . . . . . . . . . . . . . . . 3
3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 3
4. New bits in the Router LSA . . . . . . . . . . . . . . . . . . 3
5. Advertising of local addresses in the Router LSA . . . . . . . 5
6. Modification in SPF calculation . . . . . . . . . . . . . . . . 5
7. Backward compatibility . . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6
9. Security Considerations . . . . . . . . . . . . . . . . . . . . 6
10. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . 6
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6
11.1. Normative References . . . . . . . . . . . . . . . . . . . 6
11.2. Informative References . . . . . . . . . . . . . . . . . . 6
Pillay-Esnault, et al. Expires September 2, 2010 [Page 2]
Internet-Draft OSPFv2 No Transit Capability March 2010
1. Introduction
When OSPFv3 was first developed, a number of improvements were made
over the existing OSPFv2 protocol. One of these was the addition of
the R option bit in the router LSA to indicate whether the originator
is an active router. If the "R-bit" is clear, an OSPF speaker can
actively participate in the protocol without being used to forward
transit traffic.
There are a number of cases where this capability is very useful.
For example, a multi-homed BGP route reflector may want to
participate in routing, but should not be used to forward non-locally
addressed packets.
Note this is not the same capability provided by OSPF Stub Router
Advertisement [RFC3137]. That technique can be used to make a node
undesirable for transit traffic by increasing its cost, but other
routers will still compute paths through it if no others are
available.
We presuppose familiarity with the contents of [RFC5340] and
[RFC2328].
2. Specification of Requirements
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 [RFC2119].
3. Requirements
The benefits and considerations associated with deploying an OSPFv2
no-transit router are similar to those described in section 2.7 of
[RFC5340]. In addition, a no-transit router should not be an Area
Border Router or Autonomous System Boundary Router.
4. New bits in the Router LSA
Two new bits are defined in the Router-LSA to define the support and
state of the capability. The S-Bit is set to indicate that a router
has the capability to process the R-bit. The R-bit is clear when a
router is effectively functioning as a no-transit node.
S/R possible settings
1/1 - Router has capability for no-transit and is transit
1/0 - Router has capability for no-transit and is no-transit
0/x - Router does not have no-transit capability and
Pillay-Esnault, et al. Expires September 2, 2010 [Page 3]
Internet-Draft OSPFv2 No Transit Capability March 2010
is always a transit router (backward compatibility)
All routers implementing this capability MUST set the S-bit in their
Router-LSAs. The R-bit SHOULD be set unless the router does not
participate in any transit routing.
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 | Options | 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0|R|S|N|W|V|E|B| 0 | # links |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | # TOS | metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TOS | 0 | TOS metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Data |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
The OSPFv2 Router LSA with new R and S bits
R-bit
The "Router" bit indicates whether the originator is an active
router. If the router bit is clear, then routes that transit the
advertising node cannot be computed. Clearing the router bit would
be appropriate for a multi-homed host that wants to participate in
Pillay-Esnault, et al. Expires September 2, 2010 [Page 4]
Internet-Draft OSPFv2 No Transit Capability March 2010
routing, but does not want to forward non- locally addressed packets.
S-bit
The "Support" bit indicates whether the originator can process the
R-Bit.
5. Advertising of local addresses in the Router LSA
When the R-bit is clear in the router-LSA:
1. All local addresses on the router are advertised as stub links in
the router-LSA with a metric set to the interface output cost.
2. The cost of other links should be set to LSInfinity as defined in
section 2 of [RFC3137].
6. Modification in SPF calculation
The step 2 in section 16.1 of [RFC2328] is modified as follows:
Call the vertex just added to the tree vertex V. Examine the LSA
associated with vertex V. This is a lookup in the Area A's link state
database based on the Vertex ID. If this is a router-LSA, and bit V
of the router-LSA (see Section A.4.2) is set, set Area A's
TransitCapability to TRUE. In any case, each link described by the
LSA gives the cost to an adjacent vertex.
If all the router-LSAs in the area have the S-Bit set and vertex V is
a router-LSA with R-bit clear and it is not the root, then all vertex
V's links are ignored and the next vertex on the candidate list
should be examined as described in Step 3.
7. Backward compatibility
For the modification in the SPF processing defined in section 6 of
this document to take effect, all routers in the area MUST have the
S-bit set.
When an area switches from being all S-bit capable routers to a mix
of S-bit capable and non-capable, previous no-transit routers may now
considered as potential transit nodes. Likewise, when a mixed area
switches to being all S-bit capable, paths will no longer be computed
through no-transit nodes.
If a new router not supporting the R-Bit joins the area (S-bit
clear):
Pillay-Esnault, et al. Expires September 2, 2010 [Page 5]
Internet-Draft OSPFv2 No Transit Capability March 2010
1. The new step defined in section 6 of this document will be
ignored.
2. Any no-transit router with link cost set to LSInfinity will be
treated like a stub router as defined in [RFC3137].
8. IANA Considerations
This document has no actions for IANA.
9. Security Considerations
The new extensions defined in this document do not introduce any new
security concerns other than those already defined in [RFC2328].
10. Acknowledgments
The authors would like to thank Liem Nguyen and Abhay Roy for their
comments.
This document was produced using Marshall Rose's xml2rfc tool.
11. References
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2328] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008.
11.2. Informative References
[RFC3137] Retana, A., Nguyen, L., White, R., Zinin, A., and D.
McPherson, "OSPF Stub Router Advertisement", June 2001.
Pillay-Esnault, et al. Expires September 2, 2010 [Page 6]
Internet-Draft OSPFv2 No Transit Capability March 2010
Authors' Addresses
Padma Pillay-Esnault
Cisco Systems
510 McCarty Blvd
Milpitas, CA 95035
USA
EMail: ppe@cisco.com
Michael Barnes
Cisco Systems
510 McCarty Blvd
Milpitas, CA 95035
USA
EMail: mjbarnes@cisco.com
Paul Wells
Cisco Systems
510 McCarty Blvd
Milpitas, CA 95035
USA
EMail: pauwells@cisco.com
Pillay-Esnault, et al. Expires September 2, 2010 [Page 7]