draft-ietf-ospf-transport-instance-07.txt   draft-ietf-ospf-transport-instance-08.txt 
Network Working Group A. Lindem Network Working Group A. Lindem
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track A. Roy Intended status: Standards Track A. Roy
Expires: April 12, 2012 S. Mirtorabi Expires: October 6, 2012 S. Mirtorabi
Cisco Systems Cisco Systems
October 10, 2011 April 4, 2012
OSPF Transport Instance Extensions OSPF Transport Instance Extensions
draft-ietf-ospf-transport-instance-07.txt draft-ietf-ospf-transport-instance-08.txt
Abstract Abstract
OSPFv2 and OSPFv3 include a reliable flooding mechanism to OSPFv2 and OSPFv3 include a reliable flooding mechanism to
disseminate routing topology and Traffic Engineering (TE) information disseminate routing topology and Traffic Engineering (TE) information
within a routing domain. Given the effectiveness of these within a routing domain. Given the effectiveness of these
mechanisms, it is convenient to envision using the same mechanism for mechanisms, it is convenient to envision using the same mechanism for
dissemination of other types of information within the domain. dissemination of other types of information within the domain.
However, burdening OSPF with this additional information will impact However, burdening OSPF with this additional information will impact
intra-domain routing convergence and possibly jeopardize the intra-domain routing convergence and possibly jeopardize the
skipping to change at page 1, line 41 skipping to change at page 1, line 41
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on April 12, 2012. This Internet-Draft will expire on October 6, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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 Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 5, line 7 skipping to change at page 5, line 7
instance and minimize the impact. instance and minimize the impact.
1.1. Requirements notation 1.1. Requirements notation
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in [RFC-KEYWORDS]. document are to be interpreted as described in [RFC-KEYWORDS].
2. OSPF Transport Instance 2. OSPF Transport Instance
In order to isolate the overhead of flooding non-routing information, In order to isolate the effects of flooding and processing of non-
its flooding will be relegated to a separate protocol instance. This routing information, it will be relegated to a separate protocol
instance should be given lower priority when contending for router instance. This instance should be given lower priority when
resources including processing, backplane bandwidth, and line card contending for router resources including processing, backplane
bandwidth. How that is realized is an implementation issue and is bandwidth, and line card bandwidth. How that is realized is an
beyond the scope of this document. implementation issue and is outside the scope of this document.
Throughout the document, non-routing refers to routing information Throughout the document, non-routing refers to routing information
that is not used for IP or IPv6 routing calculations. The OSPF that is not used for IP or IPv6 routing calculations. The OSPF
transport instance is ideally suited for dissemination of routing transport instance is ideally suited for dissemination of routing
information for other protocols and layers. 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
skipping to change at page 5, line 36 skipping to change at page 5, line 36
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
packet encodings. The existing OSPFv3 packet header instance ID packet encodings. The existing OSPFv3 packet header instance ID
field will be used to differentiate packets received on the same link field will be used to differentiate packets received on the same link
(refer to section 2.4 in [OSPFV3]). (refer to section 2.4 in [OSPFV3]).
2.3. Instance Relationship to Normal OSPF Instances 2.3. Instance Relationship to Normal OSPF Instances
There are basically two alternatives for the relationship between a There are basically two alternatives for the relationship between a
normal OSPF instance and a Transport Instance. In both cases, we normal OSPF instance and an OSPF transport instance. In both cases,
must guarantee that any information we've received is treated as 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 valid if and only if the router sending it is reachable. We'll refer
to this as the "condition of reachability" in this document. to this as the "condition of reachability" in this document.
1. Ships in the Night - The Transport Instance has no relationship 1. Ships in the Night - The OSPF transport instance has no
or dependency on any other OSPF instance. relationship or dependency on any other OSPF instance.
2. Child Instance - The Transport Instance has a child-parent 2. Child Instance - The OSPF transport instance has a child-parent
relationship with a normal OSPF instance and is dependent on this relationship with a normal OSPF instance and is dependent on this
for topology information and assuring the "condition of for topology information and assuring the "condition of
reachability". reachability".
2.3.1. Ships in the Night Relationship to Normal OSPF Instances 2.3.1. Ships in the Night Relationship to Normal OSPF Instances
In this mode, the Transport Instance is not dependent on any other In this mode, the OSPF transport instance is not dependent on any
OSPF instance. It does, however, have much of the overhead as other OSPF instance. It does, however, have much of the same 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 not need to be advertised. This implies that
that for OSPFv2, only router-LSAs, network-LSAs, and type 4 summary- for OSPFv2, only router-LSAs, network-LSAs, and type 4 summary-LSAs
LSAs need to be advertised. In the router-LSAs, the stub (type 3) need to be advertised. In the router-LSAs, the stub (type 3) links
links may be suppressed. For OSPFv3, this implies that router-LSAs, 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. Tighter Coupling with Normal OSPF Instances 2.3.2. Tighter Coupling with Normal OSPF Instances
Further optimization and coupling between the transport instance and Further optimizations and coupling between an OSPF transport instance
a normal OSPF instance are beyond the scope of this document. This and a normal OSPF instance are beyond the scope of this document.
is an area for future study. This 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 an OSPF
instance will be sent with IP precedence Flash (B'011'). This is transport instance will be sent with IP precedence Flash (B'011').
only appropriate given that this is a pretty flashy mechanism. This is 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
implementations 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, internal router implementation decisions
of this document. are beyond the scope 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 IP or IPv6 routes. OSPF routers
advertise any transport instance LSAs containing IP or IPv6 prefixes SHOULD NOT advertise any transport instance LSAs containing IP or
and OSPF routers receiving LSAs advertising prefixes SHOULD ignore IPv6 prefixes and OSPF routers receiving LSAs advertising IP or IPv6
them. This implies that an OSPFv2 transport instance Link State prefixes SHOULD ignore them. This implies that an OSPFv2 transport
Database should not include any Summary-LSAs (type 3) , AS-External- instance Link State Database should not include any summary-LSAs
LSAs (type 5), or NSSA-LSAs (type 7) and the Router-LSAs should not (type 3) , AS-external-LSAs (type 5), or NSSA-LSAs (type 7) and the
include any stub (type 3) links. An OSPFv3 transport instance Link router-LSAs should not include any stub (type 3) links. An OSPFv3
State database should not include any Inter-Area-Prefix-LSAs (type transport instance Link State database should not include any inter-
0x2003), AS-External-LSAs (0x4005), NSSA-LSAs (type 0x2007), or area-prefix-LSAs (type 0x2003), AS-external-LSAs (0x4005), NSSA-LSAs
Intra-Area-Prefix-LSAs (type 0x2009). If they are erroneously (type 0x2007), or intra-area-prefix-LSAs (type 0x2009). If they are
advertised, they MUST be ignored by OSPF routers supporting this erroneously advertised, they will be flooded as per standard OSPF but
specification. MUST be ignored by OSPF routers supporting this specification.
2.6. Non-routing Instance Separation 2.6. Non-routing Instance Separation
It has been suggested that an implementation 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
skipping to change at page 7, line 31 skipping to change at page 7, line 32
o The instance boundary offers much better separation for allocation o The instance boundary offers much better separation for allocation
of finite resources such as buffers, memory, processor cores, of finite resources such as buffers, memory, processor cores,
sockets, and bandwidth. sockets, and bandwidth.
o The instance boundary decreases the level of fate sharing for o The instance boundary decreases the level of fate sharing for
failures. Each instance may be implemented as a separate process failures. Each instance may be implemented as a separate process
or task. or task.
o With non-routing information, many times not every router in the o With non-routing information, many times not every router in the
OSPF routing domain requires knowledge of every piece of routing OSPF routing domain requires knowledge of every piece of non-
information. In these cases, groups of routers which need to routing information. In these cases, groups of routers which need
share information can be segregated into sparse topologies greatly to share information can be segregated into sparse topologies
reducing the amount of non-routing information any single router greatly reducing the amount of non-routing information any single
needs to maintain. router needs to maintain.
2.7. Non-Routing Sparse Topologies 2.7. Non-Routing Sparse Topologies
With non-routing information, many times not every router in the OSPF With non-routing information, many times not every router in the OSPF
routing domain requires knowledge of every piece of routing routing domain requires knowledge of every piece of non-routing
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 information and every intra-area IP or IPv6 prefix.
routing information, only the routers needing to share a set of With non-routing information, only the routers needing to share a set
information need be part of the corresponding sparse topology. For of information need be part of the corresponding sparse topology.
directly attached routers, one only needs to configure the desired
topologies on the interfaces with routers requiring the non-routing For directly attached routers, one only needs to configure the
information. When the routers making up the sparse topology are not desired topologies on the interfaces with routers requiring the non-
part of a uniconnected graph, two alternatives exist. The first routing information. When the routers making up the sparse topology
alternative is configure tunnels to form a fully connected graph are not part of a uniconnected graph, two alternatives exist. The
including only those routers in the sparse topology. The second first alternative is configure tunnels to form a fully connected
alternative is use remote neighbors as described in Section 2.7.1. 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 2.7.1. Remote OSPF Neighbor
With sparse topologies, OSPF routers sharing non-routing information With sparse topologies, OSPF routers sharing non-routing information
may not be directly connected. OSPF adjacencies with remote may not be directly connected. OSPF adjacencies with remote
neighbors are formed exactly as they are with regular OSPF neighbors. neighbors are formed exactly as they are with regular OSPF neighbors.
The main difference is that a remote OSPF neighbor's address is The main difference is that a remote OSPF neighbor's address is
configured and IP routing is used to deliver packet to the remote configured and IP routing is used to deliver OSPF protocol packets to
neighbor. Other salient feature of remote neighbor include: the remote neighbor. Other salient feature of the remote neighbor
include:
o All OSPF packets are addressed to the remote neighbor's configured o All OSPF packets have the remote neighbor's configured IP address
IP address. as the IP destination address.
o The adjacency is represented in the router Router-LSA as a router 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 (type-1) link with the link data set to the remote neighbor's
address. configured IP address.
o Similar to NBMA networks, a poll-interval is configured to o Similar to NBMA networks, a poll-interval is configured to
determine if the remote neighbor is reachable. This value is determine if the remote neighbor is reachable. This value is
normally much higher than the hello interval. normally much higher than the hello interval with 40 seconds
RECOMMENDED as the default.
3. OSPF Transport Instance Information Encoding 3. OSPF Transport Instance Information Encoding
The format of the TLVs within the body of an LSA containing non- 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 routing information is the same as the format used by the Traffic
Engineering Extensions to OSPF [TE]. The LSA payload consists of one Engineering Extensions to OSPF [TE]. The LSA payload consists of one
or more nested Type/Length/Value (TLV) triplets. The format of each or more nested Type/Length/Value (TLV) triplets. The format of each
TLV is: TLV is:
0 1 2 3 0 1 2 3
skipping to change at page 11, line 7 skipping to change at page 11, line 7
with separate function codes. Refer to section A.4.2.1 of [OSPFV3] with separate function codes. Refer to section A.4.2.1 of [OSPFV3]
for information on the LS Type encoding in OSPFv3. for information on the LS Type encoding in OSPFv3.
4. Security Considerations 4. Security Considerations
The security considerations for the Transport Instance will not be The security considerations for the Transport Instance will not be
different for those for OSPFv2 [OSPFV2] and OSPFv3 [OSPFV3]. different for those for OSPFv2 [OSPFV2] and OSPFv3 [OSPFV3].
5. IANA Considerations 5. IANA Considerations
No new IANA assignments are required for this draft. No IANA actions are required.
6. References 6. References
6.1. Normative References 6.1. Normative References
[MULTI-INST] [MULTI-INST]
Lindem, A., Mirtorabi, S., and A. Roy, "OSPF Multi- Lindem, A., Mirtorabi, S., and A. Roy, "OSPF Multi-
Instance Extensions", Instance Extensions", RFC 6549, March 2012.
draft-ietf-ospf-multi-instance-02.txt (work in progress).
[OPAQUE] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The [OPAQUE] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The
OSPF Opaque LSA Option", RFC 5250, July 2008. OSPF Opaque LSA Option", RFC 5250, July 2008.
[OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [OSPFV2] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008. for IPv6", RFC 5340, July 2008.
[RFC-KEYWORDS] [RFC-KEYWORDS]
Bradner, S., "Key words for use in RFC's to Indicate Bradner, S., "Key words for use in RFCs 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.
6.2. Informative References 6.2. Informative References
[ISIS-GEN-APP] [ISIS-GEN-APP]
Ginsberg, L., Previdi, S., and M. Shand, "Advertising Ginsberg, L., Previdi, S., and M. Shand, "Advertising
Generic Information in IS-IS", Generic Information in IS-IS",
 End of changes. 25 change blocks. 
72 lines changed or deleted 76 lines changed or added

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