Network Working Group A. Lindem
Internet-Draft Ericsson
Intended status: Standards Track A. Roy
Expires: April 12, 2012 S. Mirtorabi
Cisco Systems
October 10, 2011
OSPF Transport Instance Extensions
draft-ietf-ospf-transport-instance-07.txt
Abstract
OSPFv2 and OSPFv3 include a reliable flooding mechanism to
disseminate routing topology and Traffic Engineering (TE) information
within a routing domain. Given the effectiveness of these
mechanisms, it is convenient to envision using the same mechanism for
dissemination of other types of information within the domain.
However, burdening OSPF with this additional information will impact
intra-domain routing convergence and possibly jeopardize the
stability of the OSPF routing domain. This document presents
mechanism to relegate this ancillary information to a separate OSPF
instance and minimize the impact.
Status of this Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/.
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."
This Internet-Draft will expire on April 12, 2012.
Copyright Notice
Copyright (c) 2011 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
Lindem, et al. Expires April 12, 2012 [Page 1]
Internet-Draft OSPF Transport Instance Extensions October 2011
(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 Simplified BSD License.
This document may contain material from IETF Documents or IETF
Contributions published or made publicly available before November
10, 2008. The person(s) controlling the copyright in some of this
material may not have granted the IETF Trust the right to allow
modifications of such material outside the IETF Standards Process.
Without obtaining an adequate license from the person(s) controlling
the copyright in such materials, this document may not be modified
outside the IETF Standards Process, and derivative works of it may
not be created outside the IETF Standards Process, except to format
it for publication as an RFC or to translate it into languages other
than English.
Lindem, et al. Expires April 12, 2012 [Page 2]
Internet-Draft OSPF Transport Instance Extensions October 2011
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 4
2. OSPF Transport Instance . . . . . . . . . . . . . . . . . . . 5
2.1. OSPFv2 Transport Instance Packets Differentiation . . . . 5
2.2. OSPFv3 Transport Instance Packets Differentiation . . . . 5
2.3. Instance Relationship to Normal OSPF Instances . . . . . . 5
2.3.1. Ships in the Night Relationship to Normal OSPF
Instances . . . . . . . . . . . . . . . . . . . . . . 6
2.3.2. Tighter Coupling with Normal OSPF Instances . . . . . 6
2.4. Network Prioritization . . . . . . . . . . . . . . . . . . 6
2.5. OSPF Transport Instance Omission of Routing Calculation . 6
2.6. Non-routing Instance Separation . . . . . . . . . . . . . 7
2.7. Non-Routing Sparse Topologies . . . . . . . . . . . . . . 7
2.7.1. Remote OSPF Neighbor . . . . . . . . . . . . . . . . . 8
3. OSPF Transport Instance Information Encoding . . . . . . . . . 9
3.1. OSPFv2 Transport Instance Information Encoding . . . . . . 9
3.2. OSPFv3 Transport Instance Information Encoding . . . . . . 9
4. Security Considerations . . . . . . . . . . . . . . . . . . . 10
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
6.1. Normative References . . . . . . . . . . . . . . . . . . . 12
6.2. Informative References . . . . . . . . . . . . . . . . . . 12
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
Lindem, et al. Expires April 12, 2012 [Page 3]
Internet-Draft OSPF Transport Instance Extensions October 2011
1. Introduction
OSPFv2 [OSPFV2] and OSPFv3 [OSPFV3] include a reliable flooding
mechanism to disseminate routing topology and Traffic Engineering
(TE) information within a routing domain. Given the effectiveness of
these mechanisms, it is convenient to envision using the same
mechanism for dissemination of other types of information within the
domain. However, burdening OSPF with this additional information
will impact intra-domain routing convergence and possibly jeopardize
the stability of the OSPF routing domain. This document presents
mechanism to relegate this ancillary information to a separate OSPF
instance and minimize the impact.
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-KEYWORDS].
Lindem, et al. Expires April 12, 2012 [Page 4]
Internet-Draft OSPF Transport Instance Extensions October 2011
2. OSPF Transport Instance
In order to isolate the overhead of flooding non-routing information,
its flooding will be relegated to a separate protocol instance. This
instance should be given lower priority when contending for router
resources including processing, backplane bandwidth, and line card
bandwidth. How that is realized is an implementation issue and is
beyond the scope of this document.
Throughout the document, non-routing refers to routing information
that is not used for IP or IPv6 routing calculations. The OSPF
transport instance is ideally suited for dissemination of routing
information for other protocols and layers.
2.1. OSPFv2 Transport Instance Packets Differentiation
OSPFv2 currently doesn't offer a mechanism to differentiate Transport
instance packets from normal instance packets sent and received on
the same interface. However, the [MULTI-INST] provides the necessary
packet encoding to support multiple OSPF protocol instances.
2.2. OSPFv3 Transport Instance Packets Differentiation
Fortunately, OSPFv3 already supports separate instances within the
packet encodings. The existing OSPFv3 packet header instance ID
field will be used to differentiate packets received on the same link
(refer to section 2.4 in [OSPFV3]).
2.3. Instance Relationship to Normal OSPF Instances
There are basically two alternatives for the relationship between a
normal OSPF instance and a Transport Instance. In both cases, we
must guarantee that any information we've received is treated as
valid if and only if the router sending it is reachable. We'll refer
to this as the "condition of reachability" in this document.
1. Ships in the Night - The Transport Instance has no relationship
or dependency on any other OSPF instance.
2. Child Instance - The Transport Instance has a child-parent
relationship with a normal OSPF instance and is dependent on this
for topology information and assuring the "condition of
reachability".
Lindem, et al. Expires April 12, 2012 [Page 5]
Internet-Draft OSPF Transport Instance Extensions October 2011
2.3.1. Ships in the Night Relationship to Normal OSPF Instances
In this mode, the Transport Instance is not dependent on any other
OSPF instance. It does, however, have much of the overhead as
topology information must be advertised to satisfy the condition of
reachability.
Prefix information does this need to be advertised. This implies
that for OSPFv2, only router-LSAs, network-LSAs, and type 4 summary-
LSAs need to be advertised. In the router-LSAs, the stub (type 3)
links may be suppressed. For OSPFv3, this implies that router-LSAs,
Network-LSAs, and inter-area-router-LSAs must be advertised.
2.3.2. Tighter Coupling with Normal OSPF Instances
Further optimization and coupling between the transport instance and
a normal OSPF instance are beyond the scope of this document. This
is an area for future study.
2.4. Network Prioritization
While OSPFv2 (section 4.3 in [OSPFV2]) are normally sent with IP
precedence Internetwork Control, any packets sent by a transport
instance will be sent with IP precedence Flash (B'011'). This is
only appropriate given that this is a pretty flashy mechanism.
Similarly, OSPFv3 transport instance packets will be sent with the
traffic class mapped to flash (B'011') as specified in ([OSPFV3].
By setting the IP/IPv6 precedence differently for OSPF transport
instance packets, normal OSPF routing instances can be given priority
during both packet transmission and reception. In fact, some router
implementations map the IP precedence directly to their internal
packet priority. However, implementation issues are beyond the scope
of this document.
2.5. OSPF Transport Instance Omission of Routing Calculation
Since the whole point of the transport instance is to separate the
routing and non-routing processing and fate sharing, a transport
instance SHOULD NOT install any routes. OSPF routers SHOULD NOT
advertise any transport instance LSAs containing IP or IPv6 prefixes
and OSPF routers receiving LSAs advertising prefixes SHOULD ignore
them. This implies that an OSPFv2 transport instance Link State
Database should not include any Summary-LSAs (type 3) , AS-External-
LSAs (type 5), or NSSA-LSAs (type 7) and the Router-LSAs should not
include any stub (type 3) links. An OSPFv3 transport instance Link
State database should not include any Inter-Area-Prefix-LSAs (type
Lindem, et al. Expires April 12, 2012 [Page 6]
Internet-Draft OSPF Transport Instance Extensions October 2011
0x2003), AS-External-LSAs (0x4005), NSSA-LSAs (type 0x2007), or
Intra-Area-Prefix-LSAs (type 0x2009). If they are erroneously
advertised, they MUST be ignored by OSPF routers supporting this
specification.
2.6. Non-routing Instance Separation
It has been suggested that an implementation could obtain the same
level of separation between IP routing information and non-routing
information in a single instance with slight modifications to the
OSPF protocol. The authors refute this contention for the following
reasons:
o Adding internal and external mechanisms to prioritize routing
information over non-routing information are much more complex
than simply relegating the non-routing information to a separate
instance as proposed in this specification.
o The instance boundary offers much better separation for allocation
of finite resources such as buffers, memory, processor cores,
sockets, and bandwidth.
o The instance boundary decreases the level of fate sharing for
failures. Each instance may be implemented as a separate process
or task.
o With non-routing information, many times not every router in the
OSPF routing domain requires knowledge of every piece of routing
information. In these cases, groups of routers which need to
share information can be segregated into sparse topologies greatly
reducing the amount of non-routing information any single router
needs to maintain.
2.7. Non-Routing Sparse Topologies
With non-routing information, many times not every router in the OSPF
routing domain requires knowledge of every piece of routing
information. In these cases, groups of routers which need to share
information can be segregated into sparse topologies. This will
greatly reduce the amount of information any single router needs to
maintain with the core routers possibly not requiring any non-routing
information at all.
With normal OSPF, every router in an OSPF area must have every piece
of topological and IP or IPv6 prefix routing information. With non-
routing information, only the routers needing to share a set of
information need be part of the corresponding sparse topology. For
directly attached routers, one only needs to configure the desired
Lindem, et al. Expires April 12, 2012 [Page 7]
Internet-Draft OSPF Transport Instance Extensions October 2011
topologies on the interfaces with routers requiring the non-routing
information. When the routers making up the sparse topology are not
part of a uniconnected graph, two alternatives exist. The first
alternative is configure tunnels to form a fully connected graph
including only those routers in the sparse topology. The second
alternative is use remote neighbors as described in Section 2.7.1.
2.7.1. Remote OSPF Neighbor
With sparse topologies, OSPF routers sharing non-routing information
may not be directly connected. OSPF adjacencies with remote
neighbors are formed exactly as they are with regular OSPF neighbors.
The main difference is that a remote OSPF neighbor's address is
configured and IP routing is used to deliver packet to the remote
neighbor. Other salient feature of remote neighbor include:
o All OSPF packets are addressed to the remote neighbor's configured
IP address.
o The adjacency is represented in the router Router-LSA as a router
(type-1) link with the link data set to the remote neighbor
address.
o Similar to NBMA networks, a poll-interval is configured to
determine if the remote neighbor is reachable. This value is
normally much higher than the hello interval.
Lindem, et al. Expires April 12, 2012 [Page 8]
Internet-Draft OSPF Transport Instance Extensions October 2011
3. OSPF Transport Instance Information Encoding
The format of the TLVs within the body of an LSA containing non-
routing information is the same as the format used by the Traffic
Engineering Extensions to OSPF [TE]. The LSA payload consists of one
or more nested Type/Length/Value (TLV) triplets. The format of each
TLV is:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Format
However, each unique application using the mechanisms defined in this
document will have it's own unique ID. Whether to encode this ID as
the top-level TLV or make it part of the OSPF LSA ID is open for
debate.
The specific TLVs and sub-TLVs relating to a given application and
the corresponding IANA considerations MUST for standard applications
MUST be specified in the document corresponding to that application.
3.1. OSPFv2 Transport Instance Information Encoding
Application specific information will be flooded in opaque LSAs as
specified in [OPAQUE].
3.2. OSPFv3 Transport Instance Information Encoding
Application specific information will be flooded in separate LSAs
with separate function codes. Refer to section A.4.2.1 of [OSPFV3]
for information on the LS Type encoding in OSPFv3.
Lindem, et al. Expires April 12, 2012 [Page 9]
Internet-Draft OSPF Transport Instance Extensions October 2011
4. Security Considerations
The security considerations for the Transport Instance will not be
different for those for OSPFv2 [OSPFV2] and OSPFv3 [OSPFV3].
Lindem, et al. Expires April 12, 2012 [Page 10]
Internet-Draft OSPF Transport Instance Extensions October 2011
5. IANA Considerations
No new IANA assignments are required for this draft.
Lindem, et al. Expires April 12, 2012 [Page 11]
Internet-Draft OSPF Transport Instance Extensions October 2011
6. References
6.1. Normative References
[MULTI-INST]
Lindem, A., Mirtorabi, S., and A. Roy, "OSPF Multi-
Instance Extensions",
draft-ietf-ospf-multi-instance-02.txt (work in progress).
[OPAQUE] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
OSPF Opaque LSA Option", RFC 5250, July 2008.
[OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008.
[RFC-KEYWORDS]
Bradner, S., "Key words for use in RFC's to Indicate
Requirement Levels", RFC 2119, March 1997.
[TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering
Extensions to OSPF", RFC 3630, September 2003.
6.2. Informative References
[ISIS-GEN-APP]
Ginsberg, L., Previdi, S., and M. Shand, "Advertising
Generic Information in IS-IS",
draft-ietf-isis-genapp-04.txt (work in progress).
Lindem, et al. Expires April 12, 2012 [Page 12]
Internet-Draft OSPF Transport Instance Extensions October 2011
Appendix A. Acknowledgments
The RFC text was produced using Marshall Rose's xml2rfc tool.
Although very different mechanisms are utilized, the concept of using
a separate instance to advertise non-routing information in an IGP
was first introduced in "Advertising Generic Information in IS-IS"
[ISIS-GEN-APP].
Thanks to Jonathan Sadler for comments on the document.
Lindem, et al. Expires April 12, 2012 [Page 13]
Internet-Draft OSPF Transport Instance Extensions October 2011
Authors' Addresses
Acee Lindem
Ericsson
102 Carric Bend Court
Cary, NC 27519
USA
Email: acee.lindem@ericsson.com
Abhay Roy
Cisco Systems
225 West Tasman Drive
San Jose, CA 95134
USA
Email: akr@cisco.com
Sina Mirtorabi
Cisco Systems
3 West Plumeria Drive
San Jose, CA 95134
USA
Email: sina@cisco.com
Lindem, et al. Expires April 12, 2012 [Page 14]