draft-ietf-ospf-transport-instance-00.txt   draft-ietf-ospf-transport-instance-01.txt 
Network Working Group A. Lindem Network Working Group A. Lindem
Internet-Draft Redback Networks Internet-Draft Redback Networks
Intended status: Standards Track A. Roy Intended status: Standards Track A. Roy
Expires: August 31, 2009 S. Mirtorabi Expires: November 3, 2009 S. Mirtorabi
Cisco Systems Cisco Systems
February 27, 2009 May 2, 2009
OSPF Transport Instance Extensions OSPF Transport Instance Extensions
draft-ietf-ospf-transport-instance-00.txt draft-ietf-ospf-transport-instance-01.txt
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "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.
This Internet-Draft will expire on August 31, 2009. This Internet-Draft will expire on November 3, 2009.
Copyright Notice Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info). publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights Please review these documents carefully, as they describe your rights
skipping to change at page 2, line 27 skipping to change at page 2, line 27
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3 1.1. Requirements notation . . . . . . . . . . . . . . . . . . 3
2. OSPF Transport Instance . . . . . . . . . . . . . . . . . . . 4 2. OSPF Transport Instance . . . . . . . . . . . . . . . . . . . 4
2.1. OSPFv2 Transport Instance Packets Differentiation . . . . 4 2.1. OSPFv2 Transport Instance Packets Differentiation . . . . 4
2.2. OSPFv3 Transport Instance Packets Differentiation . . . . 4 2.2. OSPFv3 Transport Instance Packets Differentiation . . . . 4
2.3. Instance Relationship to Normal OSPF Instances . . . . . . 4 2.3. Instance Relationship to Normal OSPF Instances . . . . . . 4
2.3.1. Ships in the Night Relationship to Normal OSPF 2.3.1. Ships in the Night Relationship to Normal OSPF
Instances . . . . . . . . . . . . . . . . . . . . . . 4 Instances . . . . . . . . . . . . . . . . . . . . . . 5
2.3.2. Tigher Coupling with Normal OSPF Instances . . . . . . 5 2.3.2. Tighter Coupling with Normal OSPF Instances . . . . . 5
2.4. Network Prioritization . . . . . . . . . . . . . . . . . . 5 2.4. Network Prioritization . . . . . . . . . . . . . . . . . . 5
2.5. OSPF Transport Instance Omission of Routing Calculation . 5 2.5. OSPF Transport Instance Omission of Routing Calculation . 5
2.6. Non-routing Instance Separation . . . . . . . . . . . . . 5 2.6. Non-routing Instance Separation . . . . . . . . . . . . . 6
2.7. Non-Routing Sparse Topologies . . . . . . . . . . . . . . 6 2.7. Non-Routing Sparse Topologies . . . . . . . . . . . . . . 6
2.7.1. Remote OSPF Neighbor . . . . . . . . . . . . . . . . . 7 2.7.1. Remote OSPF Neighbor . . . . . . . . . . . . . . . . . 7
3. OSPF Transport Instance Information Encoding . . . . . . . . . 8 3. OSPF Transport Instance Information Encoding . . . . . . . . . 8
3.1. OSPFv2 Transport Instance Information Encoding . . . . . . 8 3.1. OSPFv2 Transport Instance Information Encoding . . . . . . 8
3.2. OSPFv3 Transport Instance Information Encoding . . . . . . 8 3.2. OSPFv3 Transport Instance Information Encoding . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Normative References . . . . . . . . . . . . . . . . . . . . . 11 6. Normative References . . . . . . . . . . . . . . . . . . . . . 11
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 12 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
skipping to change at page 4, line 14 skipping to change at page 4, line 14
2. OSPF Transport Instance 2. OSPF Transport Instance
In order to isolate the overhead of flooding non-routing information, In order to isolate the overhead of flooding non-routing information,
its flooding will be relegated to a separate protocol instance. This its flooding will be relegated to a separate protocol instance. This
instance should be given lower priority when contending for router instance should be given lower priority when contending for router
resources including processing, backplane bandwidth, and line card resources including processing, backplane bandwidth, and line card
bandwidth. How that is realized is an implementation issue and is bandwidth. How that is realized is an implementation issue and is
beyond the scope of this document. 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 2.1. OSPFv2 Transport Instance Packets Differentiation
OSPFv2 currently doesn't offer a mechanism to differentiate Transport OSPFv2 currently doesn't offer a mechanism to differentiate Transport
instance packets from normal instance packets sent and received on instance packets from normal instance packets sent and received on
the same interface. However, the [MULTI-INST] provides the necessary the same interface. However, the [MULTI-INST] provides the necessary
packet encoding to support multiple OSPF protocol instances. packet encoding to support multiple OSPF protocol instances.
2.2. OSPFv3 Transport Instance Packets Differentiation 2.2. OSPFv3 Transport Instance Packets Differentiation
Fortunately, OSPFv3 already supports separate instances within the Fortunately, OSPFv3 already supports separate instances within the
skipping to change at page 5, line 8 skipping to change at page 5, line 18
OSPF instance. It does, however, have much of the overhead as OSPF instance. It does, however, have much of the overhead as
topology information must be advertised to satisfy the condition of topology information must be advertised to satisfy the condition of
reachability. reachability.
Prefix information does this need to be advertised. This implies Prefix information does this need to be advertised. This implies
that for OSPFv2, only router-LSAs, network-LSAs, and type 4 summary- 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) LSAs need to be advertised. In the router-LSAs, the stub (type 3)
links may be suppressed. For OSPFv3, this implies that router-LSAs, links may be suppressed. For OSPFv3, this implies that router-LSAs,
Network-LSAs, and inter-area-router-LSAs must be advertised. Network-LSAs, and inter-area-router-LSAs must be advertised.
2.3.2. Tigher Coupling with Normal OSPF Instances 2.3.2. Tighter Coupling with Normal OSPF Instances
Further optimization and coupling between the transport instance and Further optimization and coupling between the transport instance and
a normal OSPF instance are beyond the scope of this document. This a normal OSPF instance are beyond the scope of this document. This
is an area for future study. is an area for future study.
2.4. Network Prioritization 2.4. Network Prioritization
While OSPFv2 (section 4.3 in [OSPFV2]) are normally sent with IP While OSPFv2 (section 4.3 in [OSPFV2]) are normally sent with IP
precedence Internetwork Control, any packets sent by a transport precedence Internetwork Control, any packets sent by a transport
instance will be sent with IP precedence Flash (B'011'). This is instance will be sent with IP precedence Flash (B'011'). This is
only appropriate given that this is a pretty flashy mechanism. only appropriate given that this is a pretty flashy mechanism.
Similarly, OSPFv3 transport instance packets will be sent with the Similarly, OSPFv3 transport instance packets will be sent with the
traffic class mapped to flash (B'011') as specified in ([OSPFV3]. traffic class mapped to flash (B'011') as specified in ([OSPFV3].
By setting the IP/IPv6 precedence differently for OSPF transport By setting the IP/IPv6 precedence differently for OSPF transport
instance packets, normal OSPF routing instances can be given priority instance packets, normal OSPF routing instances can be given priority
during both packet transmission and reception. In fact, Some router during both packet transmission and reception. In fact, some router
implemenations map the IP precedence directly to their internal implementations map the IP precedence directly to their internal
packet priority. However, implementation issues are beyond the scope packet priority. However, implementation issues are beyond the scope
of this document. of this document.
2.5. OSPF Transport Instance Omission of Routing Calculation 2.5. OSPF Transport Instance Omission of Routing Calculation
Since the whole point of the transport instance is to separate the Since the whole point of the transport instance is to separate the
routing and non-routing processing and fate-sharing, a transport routing and non-routing processing and fate sharing, a transport
instance SHOULD NOT install any routes. OSPF routers SHOULD NOT instance SHOULD NOT install any routes. OSPF routers SHOULD NOT
advertise any transport instance LSAs containing IP or IPv6 prefixes advertise any transport instance LSAs containing IP or IPv6 prefixes
and OSPF routers receiving LSAs advertising prefixes SHOULD ignore and OSPF routers receiving LSAs advertising prefixes SHOULD ignore
them. This implies that an OSPFv2 transport instance Link State them. This implies that an OSPFv2 transport instance Link State
Database should not include any Summary-LSAs (type 3) , AS-External- 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 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 include any stub (type 3) links. An OSPFv3 transport instance Link
State database should not include any Inter-Area-Prefix-LSAs (type State database should not include any Inter-Area-Prefix-LSAs (type
0x2003), AS-External-LSAs (0x4005), NSSA-LSAs (type 0x2007), or 0x2003), AS-External-LSAs (0x4005), NSSA-LSAs (type 0x2007), or
Intra-Area-Prefix-LSAs (type 0x2009). If they are erroneously Intra-Area-Prefix-LSAs (type 0x2009). If they are erroneously
advertised, they MUST be ignored by OSPF routers supporting this advertised, they MUST be ignored by OSPF routers supporting this
specification. specification.
2.6. Non-routing Instance Separation 2.6. Non-routing Instance Separation
It has been suggested that an implementatin could obtain the same It has been suggested that an implementation could obtain the same
level of separation between IP routing information and non-routing level of separation between IP routing information and non-routing
information in a single instance with slight modifications to the information in a single instance with slight modifications to the
OSPF protocol. The authors refute this contention for the following OSPF protocol. The authors refute this contention for the following
reasons: reasons:
o Adding internal and external mechanisms to prioritize routing o Adding internal and external mechanisms to prioritize routing
information over non-routing information are much more complex information over non-routing information are much more complex
than simply relegating the non-routing information to a separate than simply relegating the non-routing information to a separate
instance as proposed in this specification. instance as proposed in this specification.
skipping to change at page 6, line 42 skipping to change at page 6, line 51
information. In these cases, groups of routers which need to share information. In these cases, groups of routers which need to share
information can be segregated into sparse topologies. This will information can be segregated into sparse topologies. This will
greatly reduce the amount of information any single router needs to greatly reduce the amount of information any single router needs to
maintain with the core routers possibly not requiring any non-routing maintain with the core routers possibly not requiring any non-routing
information at all. information at all.
With normal OSPF, every router in an OSPF area must have every piece With normal OSPF, every router in an OSPF area must have every piece
of topological and IP or IPv6 prefix routing information. With non- of topological and IP or IPv6 prefix routing information. With non-
routing information, only the routers needing to share a set of routing information, only the routers needing to share a set of
information need be part of the corresponding sparse topology. For information need be part of the corresponding sparse topology. For
directly attached routers, one only need to configure the esired directly attached routers, one only needs to configure the desired
topologies on the interfaces with routers requiring the non-routing topologies on the interfaces with routers requiring the non-routing
information. When the routers making up the sparse topology are not information. When the routers making up the sparse topology are not
part of a uniconnected graph, two alternatives exist. The first part of a uniconnected graph, two alternatives exist. The first
alternative is configure tunnels to form a fully connected graph alternative is configure tunnels to form a fully connected graph
including only those routers in the sparse topology. The second including only those routers in the sparse topology. The second
alternative is use remote neighbors as described in Section 2.7.1. alternative is use remote neighbors as described in Section 2.7.1.
2.7.1. Remote OSPF Neighbor 2.7.1. Remote OSPF Neighbor
With sparse topologies, OSPF routers sharing non-routing information With sparse topologies, OSPF routers sharing non-routing information
skipping to change at page 13, line 5 skipping to change at page 12, line 9
Bradner, S., "Key words for use in RFC's to Indicate Bradner, S., "Key words for use in RFC's to Indicate
Requirement Levels", RFC 2119, March 1997. Requirement Levels", RFC 2119, March 1997.
[TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering [TE] Katz, D., Yeung, D., and K. Kompella, "Traffic Engineering
Extensions to OSPF", RFC 3630, September 2003. Extensions to OSPF", RFC 3630, September 2003.
Appendix A. Acknowledgments Appendix A. Acknowledgments
The RFC text was produced using Marshall Rose's xml2rfc tool. The RFC text was produced using Marshall Rose's xml2rfc tool.
Thanks to Jonathan Sadler for comments on the document.
Authors' Addresses Authors' Addresses
Acee Lindem Acee Lindem
Redback Networks Redback Networks
102 Carric Bend Court 102 Carric Bend Court
Cary, NC 27519 Cary, NC 27519
USA USA
Email: acee@redback.com Email: acee@redback.com
 End of changes. 13 change blocks. 
13 lines changed or deleted 20 lines changed or added

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