< draft-srisuresh-ospf-te-05.txt   draft-srisuresh-ospf-te-06.txt >
Network Working Group P. Srisuresh Network Working Group P. Srisuresh
INTERNET-DRAFT Consultant INTERNET-DRAFT Caymas Systems, Inc.
Expires as of August 7, 2003 P. Joseph Expires as of September 3, 2004 P. Joseph
Force10 Networks Force10 Networks
February 7, 2003 March 3, 2004
OSPF-xTE: An experimental extension to OSPF for Traffic Engineering OSPF-xTE: An experimental extension to OSPF for Traffic Engineering
<draft-srisuresh-ospf-te-05.txt> <draft-srisuresh-ospf-te-06.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 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 36 skipping to change at page 1, line 36
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
This document defines OSPF-xTE, an experimental traffic engineering This document defines OSPF-xTE, an experimental traffic engineering
(TE) extension to the link-state routing protocol OSPF. New TE LSAs (TE) extension to the link-state routing protocol OSPF. OSPF-xTE
are defined to disseminate TE metrics within an autonomous defines new TE LSAs to disseminate TE metrics within an autonomous
System (AS) - intra-area as well as inter-area. An Autonomous System (AS), which may consist of multiple areas. Further, When an
System may consist of TE and non-TE nodes. Non-TE nodes are AS consists of TE and non-TE nodes, OSPF-xTE ensures that Non-TE
uneffected by the distribution of TE LSAs. A stand-alone TE Link nodes in the AS are uneffected by the TE LSAs. OSPF-xTE generates
State Database (TE-LSDB), separate from the native OSPF LSDB, is a stand-alone TE Link State Database (TE-LSDB), distinct from the
generated for the computation of TE circuit paths. OSPF-xTE is native OSPF LSDB, for computation of TE circuit paths. OSPF-xTE is
also extendible to non-packet networks such as SONET/TDM and versatile and extendible to non-packet networks such as SONET/TDM
optical networks. A transition path is provided for those using and optical networks.
[OPQLSA-TE] and wish to adapt OSPF-xTE.
Table of Contents Table of Contents
1. Introduction ................................................3 1. Introduction ................................................3
2. Principles of traffic engineering ...........................3 2. Principles of traffic engineering ...........................3
3. Terminology .................................................4 3. Terminology .................................................4
3.1. Native OSPF terms ......................................4 3.1. Native OSPF terms ......................................4
3.2. OSPF-xTE terms .........................................5 3.2. OSPF-xTE terms .........................................5
4. Motivations behind the design of OSPF-xTE ...................8 4. Motivations behind the design of OSPF-xTE ...................8
4.1. Scalable design ........................................8 4.1. Scalable design ........................................8
4.2. Operable in mixed and peer networks ....................9 4.2. Operable in mixed and peer networks ....................9
4.3. Efficient in flooding reach ............................9 4.3. Efficient in flooding reach ............................9
4.4. Ability to reserve TE-exclusive links .................10 4.4. Ability to reserve TE-exclusive links ..................9
4.5. Extendible design .....................................10 4.5. Extendible design .....................................10
4.6. Unified for packet and non-packet networks ............10 4.6. Unified for packet and non-packet networks ............10
4.7. Networks benefiting from the OSPF-xTE design ..........11 4.7. Networks benefiting from the OSPF-xTE design ..........10
5. OSPF-xTE solution overview .................................12 5. OSPF-xTE solution overview .................................11
5.1. OSPF-xTE Solution .....................................12 5.1. OSPF-xTE Solution .....................................11
5.2. Assumptions ...........................................13 5.2. Assumptions ...........................................13
6. Opaque LSAs to OSPF-xTE transition strategy ................14 6. Opaque LSAs to OSPF-xTE transition strategy ................14
7. OSPF-xTE router adjacency - TE topology discovery ..........14 7. OSPF-xTE router adjacency - TE topology discovery ..........14
7.1. The OSPF Options field ................................15 7.1. The OSPF Options field ................................15
7.2. The Hello Protocol ....................................15 7.2. The Hello Protocol ....................................15
7.3. Flooding and the Synchronization of Databases .........16 7.3. Flooding and the Synchronization of Databases .........16
7.4. The Designated Router .................................16 7.4. The Designated Router .................................16
7.5. The Backup Designated Router ..........................16 7.5. The Backup Designated Router ..........................16
7.6. The graph of adjacencies ..............................17 7.6. The graph of adjacencies ..............................17
8. TE LSAs for packet network .................................18 8. TE LSAs for packet network .................................18
skipping to change at page 3, line 18 skipping to change at page 3, line 18
engineering (TE) extension to the link-state routing protocol engineering (TE) extension to the link-state routing protocol
OSPF. The objective of OSPF-xTE is to discover TE network OSPF. The objective of OSPF-xTE is to discover TE network
topology and disseminate TE metrics within an autonomous system topology and disseminate TE metrics within an autonomous system
(AS). A stand-alone TE Link State Database (TE-LSDB), different (AS). A stand-alone TE Link State Database (TE-LSDB), different
from the native OSPF LSDB, is created to facilitate computation from the native OSPF LSDB, is created to facilitate computation
of TE circuit paths. Devising algorithms to compute TE circuit of TE circuit paths. Devising algorithms to compute TE circuit
paths is not an objective of this document. paths is not an objective of this document.
OSPF-xTE is different from the Opaque-LSA-based design outlined OSPF-xTE is different from the Opaque-LSA-based design outlined
in [OPQLSA-TE]. Section 4 describes the motivations behind the in [OPQLSA-TE]. Section 4 describes the motivations behind the
design of OSPF-xTE. Section 6 outlines a strategy to transition design of OSPF-xTE. Section 6 outlines a transition path for
Opaque-LSA based implementations to adapt OSPF-xTE. those currently using [OPQLSA-TE] and wish to experiment with
OSPF-xTE.
Readers interested in TE extensions for the packet networks Readers interested in TE extensions for the packet networks
only may skip section 9.0. alone may skip section 9.0.
2. Principles of traffic engineering 2. Principles of traffic engineering
The objective of traffic engineering (TE) is to set up circuit The objective of traffic engineering (TE) is to set up circuit
path(s) between a pair of nodes or links and to forward traffic path(s) between a pair of nodes or links and to forward traffic
of a certain forwarding equivalency class (FEC) through the of a certain forwarding equivalency class (FEC) through the
circuit path. Only the unicast circuit paths are considered circuit path. Only the unicast circuit paths are considered
in this section. Multicast variations are outside the scope. in this section. Multicast variations are outside the scope.
A traffic engineered circuit path is uni-directional and may A traffic engineered circuit path is uni-directional and may
skipping to change at page 9, line 12 skipping to change at page 9, line 12
OSPF-xTE area level abstraction provides the scaling required OSPF-xTE area level abstraction provides the scaling required
for the TE topology in a large autonomous system (AS). for the TE topology in a large autonomous system (AS).
An OSPF-xTE area border router will advertise summary LSAs for An OSPF-xTE area border router will advertise summary LSAs for
TE and non-TE topologies independent of each other. Readers TE and non-TE topologies independent of each other. Readers
may refer to section 10 for a topological view of the AS from may refer to section 10 for a topological view of the AS from
the perspective of a OSPF-xTE node in an area. the perspective of a OSPF-xTE node in an area.
4.2. Operable in mixed and peer networks 4.2. Operable in mixed and peer networks
OSPF-xTE regards an AS as constituted of a TE and non-TE networks OSPF-xTE assumes that an AS may be constituted of coexisting
coexisting within the same bounds. OSPF-xTE dynamically discovers TE and non-TE networks. OSPF-xTE dynamically discovers TE
TE topology and the associated TE metrics of the nodes and links topology and the associated TE metrics of the nodes and links
within, just as the native OSPF does of a non-TE network. An that form the TE network. As such, OSPF-xTE generates a
independent TE-LSDB, representative of the TE topology is stand-alone TE-LSDB that is fully representative of the TE
generated as a result. A stand-alone TE-LSDB allows for speedy network. Stand-alone TE-LSDB allows for speedy TE computations.
searches through the database.
In [OPQLSA-TE], the TE-LSDB is derived from the combination of In [OPQLSA-TE], the TE-LSDB is derived from the combination of
opaque LSAs and native LSDB. Further, the TE-LSDB thus derived has opaque LSAs and native LSDB. Further, the TE-LSDB thus derived has
no knowledge of the TE capabilities of the routers in the network. no knowledge of the TE capabilities of the routers in the network.
4.3. Efficient in flooding reach 4.3. Efficient in flooding reach
OSPF-xTE is able to identify the TE topology in a mixed network OSPF-xTE is able to identify the TE topology in a mixed network
and will limit the flooding of TE LSAs to just the TE-nodes. and will limit the flooding of TE LSAs to just the TE-nodes.
Non-TE nodes are not bombarded with TE LSAs. Non-TE nodes are not bombarded with TE LSAs.
skipping to change at page 9, line 51 skipping to change at page 9, line 50
just a subset of the metrics that are prone to rapid changes. just a subset of the metrics that are prone to rapid changes.
The more frequent and wider the flooding frequency, the larger The more frequent and wider the flooding frequency, the larger
the number of retransmissions and acknowledgements. The same the number of retransmissions and acknowledgements. The same
information (needed or not) may reach a router through multiple information (needed or not) may reach a router through multiple
links. Even if the router did not forward the information past links. Even if the router did not forward the information past
the node, it would still have to send acknowledgements across the node, it would still have to send acknowledgements across
all the various links on which the LSAs tried to converge. all the various links on which the LSAs tried to converge.
It is undesirable to flood non-TE nodes with TE information. It is undesirable to flood non-TE nodes with TE information.
[OPQLSA-TE] uses Opaque LSAs for advertising TE information.
Opaque LSAs reach all nodes within the network - TE-nodes and
non-TE nodes alike. [OPQLSA-TE] also does not have provision
to advertise just the TLVs that changed. A change in any TLV
of a link will mandate the entire LSA to be transmitted.
4.4. Ability to reserve TE-exclusive links 4.4. Ability to reserve TE-exclusive links
OSPF-xTE draws a clear distinction between TE and non-TE OSPF-xTE draws a clear distinction between TE and non-TE
links. A TE link may be configured to permit TE traffic links. A TE link may be configured to permit TE traffic
alone, and not permit best-effort IP traffic on the link. alone, and not permit best-effort IP traffic on the link.
This permits TE enforceability on the TE links. This permits TE enforceability on the TE links.
When links of a TE-topology do not overlap the links of a When links of a TE-topology do not overlap the links of a
native IP network, OSPF-xTE allows for virtual isolation of native IP network, OSPF-xTE allows for virtual isolation of
the two networks. Best-effort IP network and TE network often the two networks. Best-effort IP network and TE network often
skipping to change at page 10, line 39 skipping to change at page 10, line 32
inundate the link with best-effort IP traffic, thereby inundate the link with best-effort IP traffic, thereby
rendering the link unusable for TE purposes. rendering the link unusable for TE purposes.
4.5. Extendible design 4.5. Extendible design
OSPF-xTE design is based on the tried and tested OSPF paradigm, OSPF-xTE design is based on the tried and tested OSPF paradigm,
and inherits all the benefits of the OSPF, present and future. and inherits all the benefits of the OSPF, present and future.
TE-LSAs are extendible, just as the native OSPF on which TE-LSAs are extendible, just as the native OSPF on which
OSPF-xTE is founded. OSPF-xTE is founded.
[OPQLSA-TE], on the other hand, is constrained by the semantics
of the Opaque LSA on which it is founded. The content within an
Opaque LSA is restricted to being in the form of TLVs and
sub-TLVs, some of which are mandatory. Opaque LSAs are also
restrictive when the flooding scope is required to be different
from the scope of the opaque LSA itself.
4.6. Unified for packet and non-packet networks 4.6. Unified for packet and non-packet networks
OSPF-xTE is usable within a packet network or a non-packet OSPF-xTE is usable within a packet network or a non-packet
network or a combination peer network. network or a combination peer network.
Signaling protocols such as RSVP and LDP work the same across Signaling protocols such as RSVP and LDP work the same across
packet and non-packet networks. Signaling protocols merely need packet and non-packet networks. Signaling protocols merely need
the TE characteristics of nodes and links so they can signal the the TE characteristics of nodes and links so they can signal the
nodes to formulate TE circuit paths. In a peer network, the nodes to formulate TE circuit paths. In a peer network, the
underlying control protocol must be capable of providing a underlying control protocol must be capable of providing a
unified LSDB for all TE nodes (nodes with packet-TE links as well unified LSDB for all TE nodes (nodes with packet-TE links as well
as non-packet-TE links) in the network. OSPF-xTE meets this as non-packet-TE links) in the network. OSPF-xTE meets this
requirement. requirement.
[OPQLSA-TE] is limited in scope for packet networks and does
not have provision to distinguish between node types within
a TE network.
4.7. Networks benefiting from the OSPF-xTE design 4.7. Networks benefiting from the OSPF-xTE design
Below are examples of some real-world network scenarios that Below are examples of some real-world network scenarios that
benefit from OSPF-xTE. benefit from OSPF-xTE.
4.7.1. IP providers transitioning to provide TE services 4.7.1. IP providers transitioning to provide TE services
Providers needing to support MPLS based TE in their IP network Providers needing to support MPLS based TE in their IP network
may choose to transition gradually. Perhaps, add new TE links may choose to transition gradually. Perhaps, add new TE links
or convert existing links into TE links within an area first or convert existing links into TE links within an area first
and progressively advance to offer in the entire AS. and progressively advance to offer in the entire AS.
Not all routers will support TE extensions at the same time Not all routers will support TE extensions at the same time
during the migration process. Use of TE specific LSAs and their during the migration process. Use of TE specific LSAs and their
flooding to OSPF-xTE only nodes will allow the vendor to flooding to OSPF-xTE only nodes will allow the vendor to
introduce MPLS TE without destabilizing the existing network. introduce MPLS TE without destabilizing the existing network.
The native OSPF-LSDB will remain undisturbed while newer TE The native OSPF-LSDB will remain undisturbed while newer TE
skipping to change at page 12, line 19 skipping to change at page 11, line 47
non-packet TE networks. non-packet TE networks.
(a) "Positional-Ring" type network LSA and (a) "Positional-Ring" type network LSA and
(b) Router Proxying - allowing a router to advertise on behalf (b) Router Proxying - allowing a router to advertise on behalf
of other nodes (that are not Packet/OSPF capable). of other nodes (that are not Packet/OSPF capable).
5. OSPF-xTE solution overview 5. OSPF-xTE solution overview
5.1. OSPF-xTE Solution 5.1. OSPF-xTE Solution
A new TE flag is introduced within the OSPF options field to A new TE flag is introduced within the OSPF options field to
to enable discovery of TE topology. Section 8.0 describes the enable discovery of TE topology. Section 8.0 describes the
semantics of the TE flag. TE LSAs are designed for use by the semantics of the TE flag. TE LSAs are designed for use by the
OSPF-xTE nodes. Section 9.0 describes the TE LSAs in detail. OSPF-xTE nodes. Section 9.0 describes the TE LSAs in detail.
Changes required of the OSPF data structures to support Changes required of the OSPF data structures to support
OSPF-xTE are described in section 11.0. A new TE-neighbors data OSPF-xTE are described in section 11.0. A new TE-neighbors data
structure will be used to flood TE LSAs along TE-topology. structure will be used to flood TE LSAs along TE-topology.
An OSPF-xTE node will have the native LSDB and the TE-LSDB, An OSPF-xTE node will have the native LSDB and the TE-LSDB,
A native OSPF node will have just the native LSDB. A native OSPF node will have just the native LSDB.
Consider the following OSPF area constituted of OSPF-xTE and Consider the following OSPF area constituted of OSPF-xTE and
native OSPF routers. Nodes RT1, RT2, RT3 and RT6 are OSPF-xTE native OSPF routers. Nodes RT1, RT2, RT3 and RT6 are OSPF-xTE
routers with TE and non-TE link attachments. Nodes RT4 and RT5 routers with TE and non-TE link attachments. Nodes RT4 and RT5
are native OSPF routers with no TE links. When the LSA database are native OSPF routers with no TE links. When the LSA database
skipping to change at page 37, line 17 skipping to change at page 37, line 17
used by the OSPF protocol itself. It may be used to communicate used by the OSPF protocol itself. It may be used to communicate
information between AS boundary routers; the precise nature of information between AS boundary routers; the precise nature of
such information is outside the scope of this specification. such information is outside the scope of this specification.
9. TE LSAs for non-packet network 9. TE LSAs for non-packet network
A non-packet network would use the TE LSAs described in the A non-packet network would use the TE LSAs described in the
previous section for a packet network with some variations. previous section for a packet network with some variations.
These variations are described in the following subsections. These variations are described in the following subsections.
Two new LSAs, TE-Positional-ring-network LSA and Two new LSAs, TE-Positional-ring-network LSA and TE-Router-Proxy
TE-Router-Proxy LSA are defined for explicit use in LSA are defined for use in non-packet TE networks.
non-packet TE networks.
Readers may refer to [SONET-SDH] for a detailed description of Readers may refer to [SONET-SDH] for a detailed description of
the terms used in the context of SONET/SDH TDM networks, the terms used in the context of SONET/SDH TDM networks,
9.1. TE-Router LSA (0x81) 9.1. TE-Router LSA (0x81)
The following fields are used to describe each router link (i.e., The following fields are used to describe each router link (i.e.,
interface). Each router link is typed (see the below Type field). interface). Each router link is typed (see the below Type field).
The Type field indicates the kind of link being described. The Type field indicates the kind of link being described.
skipping to change at page 46, line 41 skipping to change at page 46, line 41
TE-LINK-TLV-COLOR Section 8.1.4.6 0x0006 TE-LINK-TLV-COLOR Section 8.1.4.6 0x0006
TE-LINK-TLV-NULL Section 8.1.4.7 0x8888 TE-LINK-TLV-NULL Section 8.1.4.7 0x8888
TE-NODE-TLV-MPLS-SWITCHING Section 8.1.2.1 0x8001 TE-NODE-TLV-MPLS-SWITCHING Section 8.1.2.1 0x8001
TE-NODE-TLV-MPLS-SIG-PROTOCOLS Section 8.1.2.2 0x8002 TE-NODE-TLV-MPLS-SIG-PROTOCOLS Section 8.1.2.2 0x8002
TE-NODE-TLV-CSPF-ALG Section 8.1.2.3 0x8003 TE-NODE-TLV-CSPF-ALG Section 8.1.2.3 0x8003
TE-NODE-TLV-NULL Section 8.1.2.4 0x8888 TE-NODE-TLV-NULL Section 8.1.2.4 0x8888
13. Acknowledgements 13. Acknowledgements
The authors wish to specially thank Chitti Babu and his team The authors wish to specially thank Chitti Babu and his team
for verifying several portions of the specification in a for implementing the protocol specified in a packet network
and verifying several portions of the specification in a
mixed packet network. The authors also wish to thank Vishwas mixed packet network. The authors also wish to thank Vishwas
Manral, Riyad Hartani and Tricci So for their valuable Manral, Riyad Hartani and Tricci So for their valuable
comments and feedback on the draft. Lastly, the authors wish comments and feedback on the draft. Lastly, the authors wish
to thank Alex Zinin and Mike Shand for their draft (now to thank Alex Zinin and Mike Shand for their draft (now
defunct) titled "Flooding optimizations in link state routing defunct) titled "Flooding optimizations in link state routing
protocols". The draft provided inspiration to the authors to protocols". The draft provided inspiration to the authors to
be sensitive to the high flooding rate, likely in TE networks. be sensitive to the high flooding rate, likely in TE networks.
14. Security Considerations 14. Security Considerations
skipping to change at page 48, line 34 skipping to change at page 48, line 35
[OSPF-v2] Moy, J., "OSPF Version 2", RFC 2328, April 1998. [OSPF-v2] Moy, J., "OSPF Version 2", RFC 2328, April 1998.
[SEC-OSPF] Murphy, S., Badger, M., and B. Wellington, "OSPF with [SEC-OSPF] Murphy, S., Badger, M., and B. Wellington, "OSPF with
Digital Signatures", RFC 2154, June 1997 Digital Signatures", RFC 2154, June 1997
16. Informative References 16. Informative References
[RSVP-TE] Awduche, D., L. Berger, D. Gan, T. Li, V. Srinivasan, [RSVP-TE] Awduche, D., L. Berger, D. Gan, T. Li, V. Srinivasan,
and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP
Tunnels", RFC3209, IETF, December 2001 Tunnels", RFC 3209, IETF, December 2001
[CR-LDP] Jamoussi, B. et al, "Constraint-Based LSP Setup [CR-LDP] Jamoussi, B. et al, "Constraint-Based LSP Setup
using LDP", draft-ietf-mpls-cr-ldp-06.txt, using LDP", RFC 3212, January 2002.
Work in Progress.
[MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, [MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584,
March 1994. March 1994.
[NSSA] Coltun, R., V. Fuller and P. Murphy, "The OSPF NSSA [NSSA] P. Murphy, "The OSPF NSSA Option", RFC 3101, January
Option", draft-ietf-ospf-nssa-update-11.txt, Work in 2003
Progress.
[OPAQUE] Coltun, R., "The OSPF Opaque LSA Option," RFC 2370, [OPAQUE] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370,
July 1998. July 1998.
[OPQLSA-TE] Katz, D., D. Yeung and K. Kompella, "Traffic [OPQLSA-TE] Katz, D., D. Yeung and K. Kompella, "Traffic
Engineering Extensions to OSPF", work in progress,
<draft-katz-yeung-ospf-traffic-09.txt> Engineering Extensions to OSPF", RFC 3630, September
2003.
[SONET-SDH] Ming-CHwan Chow, "Understanding SONET/SDH Standards [SONET-SDH] Ming-CHwan Chow, "Understanding SONET/SDH Standards
and Applications" - A paperback or bound book, and Applications" - A paperback or bound book,
Published by Andan publisher. Published by Andan publisher.
[GMPLS-TE] P.A. Smith et. al, "Generalized MPLS - Signaling [GMPLS-TE] L. Berger, "Generalized Multi Protocol Label
Functional Description", work in progress, Switching (GMPLS) Signaling Functional Description",
draft-ietf-mpls-generalized-signaling-09.txt RFC 3471, January 2003
Authors' Addresses Authors' Addresses
Pyda Srisuresh Pyda Srisuresh
Consultant Caymas Systems, Inc.
849 Erie circle 1179-A North McDowell Blvd.
Milpitas, CA 95035 Petaluma, CA 94954
U.S.A. U.S.A.
EMail: srisuresh@yahoo.com EMail: srisuresh@yahoo.com
Paul Joseph Paul Joseph
Force10 Networks Force10 Networks
1440 McCarthy Boulevard 1440 McCarthy Boulevard
Milpitas, CA 95035 Milpitas, CA 95035
U.S.A. U.S.A.
EMail: pjoseph@Force10Networks.com EMail: pjoseph@Force10Networks.com
 End of changes. 25 change blocks. 
67 lines changed or deleted 47 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/