Network Working Group S. Giacalone
INTERNET-DRAFT Predictive Systems
Expiration Date: September 2001
Filename: draft-giacalone-te-optical-next-02.txt March 2001
Network Engineering Extensions (NEXT) for OSPFv3
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. 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.
Abstract
This memo defines traffic engineering extensions to OSPFv3 [2]. This
set of extensions is termed Network Engineering eXTensions for
OSPFv3, or NEXT.
NEXT enables OSPFv3 to discern and advertise holistic state and
capability data. NEXT may be used to build and present complex "best
network paths" to outside protocols such as CR-LDP and RSVP-TE.
NEXT is specifically designed to support the MPLS control plane, and
does not intend to alter native packet routing.
Since NEXT inter-operates with OSPFv3, it is essentially network
protocol independent. Therefore, when used with OSPFv3, NEXT and MPLS
can support advanced services without limiting networks to IPv4.
Please send comments to ospf@discuss.microsoft.com.
Copyright Notice
Copyright (C) The Internet Society (2001). All Rights Reserved.
Expires September 2001 [Page 1]
Internet Draft NEXT for OSPFv3 March, 2001
Table of Contents
1 Overview ............................................
2 Basic Functionality .................................
2.1 Protected Wavelength Routing ......................
2.2 Limiting Resource Consumption .....................
2.2.1 Controlling Implementations .....................
2.2.2 Separating data into LSAs .......................
2.2.3 Control Channels ................................
2.2.4 Edge Operation . ................................
2.3 Maintaining Network Stability .....................
2.4 Topology and Computation ..........................
2.5 NEXT Time and Origination Parameters ..............
NEXT LSA Formats ......................................
Overview NEXT TLVs ....................................
Depiction of the NEXT TLV hierarchy ...................
NEXT-LSA TLVs .........................................
NEXT-LSA level-1 TLVs .................................
The NEXT-Interface level-1 TLV ........................
The Next-Node level-1 TLV .............................
NEXT-Interface TLV Related level-2 TLVs ...............
Link Type Level-2 TLV .................................
Shared Risk Group Level-2 TLV .........................
Administrative Metric Level-2 TLV .....................
Bandwidth Level-2 TLV .................................
Resource Class/Color Level-2 TLV ......................
NEXT-Interface TLV Related Level-3 TLVs ...............
Data Control Channel (DCC) level-3 TLV ................
NEXT-Node Related level-2 TLVs ........................
System Resource Class/Color Level-2 TLV ...............
NEXT-Dynamic-LSA Related TLVs .........................
NEXT-Dynamic-LSA level-1 TLVs .........................
The NEXT-Dynamic-Interface Level-1 TLV ................
The NEXT-Dynamic-Node Level-1 TLV .....................
NEXT-Dynamic-Interface TLV Related level-2 TLVs .......
Unreserved Bandwidth Level-2 TLV ......................
Delay Average Level-2 TLV .............................
Reliability Level-2 TLV ...............................
Available Spectra Level-2 TLV .........................
NEXT-Dynamic-Node related level-2 TLVs ................
System Error Level-2 TLV ..............................
Acknowledgements ......................................
References ............................................
A Compatibility .......................................
A.1 NEXT operation with resource class/color and COS ..
A.2 Basic Compatibility Criteria ......................
A.3 Unnumbered Links ..................................
B NEXT State and the end-to-end argument ..............
Security Considerations ...............................
Authors' Addresses ....................................
Full Copyright Statement ..............................
Expires September 2001 [Page 2]
Internet Draft NEXT for OSPFv3 March, 2001
1 Overview
This document details extensions to OSPFv3 [2] called NEXT. NEXT can
be used to provide granular traffic engineering capabilities to
OSPFv3 devices. To accomplish this, NEXT provides interface, link,
and device capability and state information to other protocols. The
intent of NEXT is to enable the selection of shortest paths through
networks based on sets of advanced criteria.
While NEXT builds on functionality presented in other works, it adds
new features, presents new possibilities, and is intended for use
with OSPFv3.
Since it operates with OSPFv3, which is essentially network protocol
independent, NEXT can be used to enable the provisioning of advanced
MPLS services for non IPv4 networks.
NEXT supports intra-area and inter-area routing.
2 Basic Functionality
NEXT adds new LSAs to OSPFv3, and as (generally) conceived with other
OSPFv3 LSAs, NEXT LSAs will be encapsulated in IPv6 packets.
NEXT is based on a hierarchical series of type/length/value (TLV)
triplets which reside in NEXT OSPFv3 LSAs. The TLV is the most basic
component of NEXT.
NEXT TLVs may carry sub-TLVs, each conveying more specific data. The
ability of TLVs to hierarchically nest other TLVs is described in
terms of levels, Level-1 being the first, or highest TLV level.
Topological views of a network derived from NEXT may not be
synchronized with the regular OSPFv3 routed topology.
2.1 Protected Wavelength Routing
NEXT supports the reservation of alternate standby paths to a
specific destination. Protected path setup is support is provided by
the Shared Risk Link Group TLV (described elsewhere).
2.2 Limiting Resource Consumption
This memo includes several recommendations for reducing NEXT related
resource consumption.
2.2.1 Controlling Implementations
Expires September 2001 [Page 3]
Internet Draft NEXT for OSPFv3 March, 2001
To minimize memory and processing requirements, implementations do
not need to support more than 8 NEXT sub-level (level 2 and 3) TLVs
at one time. Supporting more than this number at one time is
optional.
Additionally, there is a minimalistic set of NEXT TLVs required for
interoperability and compatibility with this specification. These
TLVs are specified elsewhere in this memo.
Network operators must determine which TLVs are needed, balancing the
benefits of NEXT data against resource consumption. Obviously, only
critical TLVs should be enabled. Therefor, this memo assumes that
network operators will only enable a subset of all TLVs available in
an implementation.
2.2.2 Separating data into LSAs
NEXT splits dynamically changing TLVs, such as averages, into
separate LSAs from more static TLVs, such as color, in order to
reduce the amount aggregate TLV data transmitted.
2.2.3 Control Channels
To minimize the amount of data injected into a network, NEXT
supports the assignment of control channels. This functionality is
implemented by the DCC level-3 TLV, and the Total and Available
Spectra level-2 TLVs, described elsewhere in this memo.
2.2.4 Edge Operation
In order to reduce the memory and processing requirements of interior
routing devices, when NEXT is being used to provide data for building
explicit paths, such as E-LSPs or lightpaths, only edge devices need
to store NEXT LSAs and possibly compute topology. Therefor, in some
cases, only edge devices require additional resources for these
purposes. However, all devices running NEXT must originate and
forward NEXT LSAs
2.3 Maintaining Network Stability
NEXT does not intend to alter packet-by-packet (native OSPF) routing.
NEXT provides additional data to other protocols for uses outside the
scope of this memo. Therefor, routing oscillations caused by NEXT are
limited to the protocols that use NEXT data (for example CR-LDP).
Normal traffic follows normal OSPFv3 routing when NEXT is in use.
NEXT topology data may be used by outside protocols to route resource
reservation requests, or set up explicit network paths. Careful
design and implementation of outside protocols will increase network
stability. For example, outside protocols using NEXT data to set up
explicit routes should be very diligent in tearing down and
Expires September 2001 [Page 4]
Internet Draft NEXT for OSPFv3 March, 2001
rebuilding paths. Once a resource-reserved path is set up, NEXT path
metric changes should not automatically cause existing paths to
change.
NEXT defines several TLVs which must not be re-originated when router
event counters are cleared. These TLVs must be re-originated only
through commands designed to trigger this action. This rule applies
to any TLV which polls device or interface counters which can be
manually reset.
Special care must be taken with the general origination intervals of
several NEXT TLVs, including those based on counters or dynamic
states. The state polling intervals NEXT uses to build TLV metrics
must be manually configurable. All counter based TLVs must default to
a 5 minute counter polling average.
Additionally, [10] describes methods for smoothing the variance
between differing metrics. Using this technique, it may be possible
to limit oscillations.
2.4 Topology and Computation
Although network topology computation is outside the scope of this
memo, note that it would be beneficial if outside protocols can build
separate, modified singular, or composite (totally singular) views of
the network using the data presented by NEXT.
Separate topological views result from utilizing NEXT to build
separate "best paths" based on one NEXT state parameter.
Alternatively, NEXT may be used to modify the normal topology
process, building (complex) composite metrics, thereby modifying the
normal singular view of the network.
Lastly, NEXT LSA data may be used to build singular topologies based
on sets of state and capability data. In this case, a single best
path would be computed based on the links which support the highest
number of requested parameters and capabilities, and the best metrics
for all the requested states. Note that this functionality implies
that all metrics are inspected and treated equally by the traffic
engineering mechanism, unless configured otherwise. An example of
this type of mechanism can be found in [10].
NEXT implementations must permit direct access to NEXT LSAs and
databases.
2.5 NEXT Time and Origination Parameters
Normally, routers will originate NEXT LSAs as
contents change, and whenever otherwise required by OSPF (an LSA
refresh, for example)[3].
Expires September 2001 [Page 5]
Internet Draft NEXT for OSPFv3 March, 2001
Refer to the section entitled limiting resource consumption for more
information regarding resource consumption issues.
Upon reception of a changed NEXT LSA, routers should update their
NEXT database/s.
TLVs not enabled MUST not be added to LSAs or nested within other
TLVs.
Enabling NEXT parameters may result in LSA re-origination.
NEXT LSA Formats
NEXT LSAs follow the basic OSPFv3 packet and LSA header constructs.
Each NEXT LSA is contained within a standard OSPFv3 packet header as
in [2]:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | Type | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Additionally, each NEXT LSA begins with the standard OSPFv3 LSA
Header [2]:
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 | LS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NEXT defines new OSPFv3 LSAs, including:
Expires September 2001 [Page 6]
Internet Draft NEXT for OSPFv3 March, 2001
-The NEXT-LSA: The NEXT-LSA carries data that is likely to be
somewhat static. For example, this LSA might carry data pertaining to
administrative metrics, which tend not to change frequently.
-The NEXT-Dynamic-LSA: The NEXT-Dynamic-LSA carries data that is
likely to change frequently. For example, the NEXT-Dynamic-LSA will
carry information such as average state data, which will tend to
change every polling interval.
NEXT splits static and dynamic data into separate LSAs in order to
reduce protocol overhead.
Both LSAs carry data which pertains to interface and nodal state and
capability.
All NEXT LSAs will be identified using unallocated LS-type [2] bit
space.
NEXT follows the same rules for LSA origination, flooding, and
reception as those presented in [2]
Within the LS type of each NEXT LSA header, the U bit must be set to
1 (store and flood). The flooding scope bits S1 and S2 must be set to
0 and 1 (Area Scope) respectively.
All options field allocations are TBD.
Specialized use of NEXT LSA ID fields is TBD. Until such
specifications are made, NEXT LSA ID fields carry the same meaning as
the intra-area-prefix LSA [2].
Overview of NEXT TLVs
As noted earlier, the actual payload of each NEXT LSA is comprised of
a nested series of TLVs. The first layer of TLVs are referred to as
level-1 TLVs, the following level as level-2, and so on.
Both NEXT LSAs, the NEXT-LSA and the NEXT-Dynamic-LSA, utilize the
same TLV architecture. The NEXT TLV architecture follows the common
triplet format:
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... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As in [3], the length field defines the TLV's value length field in
bytes. A TLV with no value field would have a corresponding length of
Expires September 2001 [Page 7]
Internet Draft NEXT for OSPFv3 March, 2001
zero. TLVs must be padded to a four-byte alignment, however, padding
is not included in the length field. For example, a three byte value
would have a length of three, but the total size of the TLV would be
eight bytes. All Nested TLVs must be 32-bit aligned.
Unrecognized TLV types must be ignored. All TLVs types between 1 and
9, and above 131000 are reserved for future use. All TLV types
between 400 and 6000 are reserved for protocol specific functions.
All TLV types between 16384 and 32767 are reserved for vendor-
specific extensions. In order to facilitate changes, base NEXT TLVs
must be assigned with types at intervals of five. All other undefined
TLV type codes are reserved for future assignment.
All reserved fields are currently not utilized and must be set to
zero.
NEXT level-1 TLVs carry nested level-2 TLVs, each conveying more
specific data. Level-2 TLVs must conform the same architectural and
operative constraints as level-1 TLVs. Note level-2 TLVs may, in
turn, carry further nested level-3 TLVs. Level-3 TLVs must conform to
the same architectural and operative constraints as other TLVs. Note
level-3 TLVs may also, in turn, carry further nested TLVs.
The number of TLVs subordinate to a higher level TLV may vary, but it
must be possible for a single sub-level (lower than level-1) TLV to
be sent. The specific number of TLVs related to a higher Level TLV
should permit optimum network convergence. Unnecessary TLVs should
not be sent. Disabled TLVs should not be sent.
Note that NEXT LSAs DO NOT define the same sub-level TLVs.
Implementations of NEXT must allow TLV values to be manually
overridden.
Several TLVs must not be re-originated when router event counters are
cleared. These TLVs must only be re-originated via commands designed
to trigger this action.
Special care must be taken with the general origination intervals of
several TLVs.
Sub-level TLVs will be ordered as appropriate. There may be instances
when certain TLVs must be ordered in a specific fashion.
Depiction of the NEXT TLV hierarchy
+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+
| NEXT-LSA | | NEXT-Dynamic-LSA |
+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+
| |
-------- -------
Expires September 2001 [Page 8]
Internet Draft NEXT for OSPFv3 March, 2001
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ |
| |NEXT-Node level 1 TLV| |NEXT-Node level 1 TLV| |
| +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+
| NEXT-Interface | | | | NEXT-Interface |
| level-1 TLV | | | | level-1 TLV |
+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+
| | | |
| +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ |
| | Static Nodal | | Dynamic Nodal | |
| | level-2 TLVs | | level-2 TLVs | |
| +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ |
| | | |
+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+
| Static Interface | | | | Dynamic Interface |
| level-2 TLVs | | | | level-2 TLV |
+-+-+-+-+-+-+-+-+-+-+-+ | | +-+-+-+-+-+-+-+-+-+-+-+
| +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ |
| | Static Nodal | | Dynamic Nodal | |
| | level-3 TLVs | | level-3 TLVs | |
| |(related to specific | |(related to specific | |
| | level-2 TLVs) | | level-2 TLVs) | |
| +-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+ |
| |
+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+
| Static Interface | | Dynamic Interface |
| level-3 TLVs | | level-2 TLV |
|(related to specific | |(related to specific |
| level-2 TLVs) | | level-2 TLVs) |
+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+
NEXT-LSA TLVs
This section specifies TLVs which are only used with the NEXT-LSA.
The NEXT-LSA incorporates TLVs which convey generally static
information.
NEXT-LSA level-1 TLVs
NEXT-LSA Level-1 TLVs follow the OSPFv3 LSA header of an NEXT-LSA.
NEXT currently defines the following level-1 TLVs for the NEXT-LSA:
Type Description
---------------------------------------------------
10 The NEXT-interface TLV
15 The NEXT-node TLV
Inter area support is TBD.
Expires September 2001 [Page 9]
Internet Draft NEXT for OSPFv3 March, 2001
The NEXT-Interface level-1 TLV
The NEXT-Interface level-1 TLV granularly describes a single network
device interface. The NEXT-interface TLV contains core values and a
set of nested level-2 TLVs.
Similar to parts of the Intra-Area-Prefix LSA [2], the architecture
of the NEXT-interface 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 (10) | length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved | Referenced LS type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Referenced Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Referenced Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Level2 TLVs |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
As in [2], the combined values of Referenced LS type, Referenced Link
State ID, and Referenced Advertising Router identify the router-LSA
or network-LSA and interface which NEXT-interface information should
be associated with. If Referenced LS type is 1, the prefixes are
associated with a router-LSA, Referenced Link
State ID should be 0 and Referenced Advertising Router should be
the originating router's Router ID. If Referenced LS type is 2,
the prefixes are associated with a network-LSA, Referenced Link
State ID should be the Interface ID of the link's Designated
Router and Referenced Advertising Router should be the Designated
Router's Router ID.
By utilizing LSA referencing [2], the NEXT-interface LSA does not
need to advertise neighboring routers and/or links to determine and
identify redundant topologies.
Note that under future specification it may be possible to use the
reserved space in the base NEXT-Interface TLV to identify
technologies or protocols.
The remainder of the NEXT-interface TLV is comprised of level-2 TLVs.
The NEXT-Node level-1 TLV
A NEXT-Node TLV describes a system which is running OSPFv3 and NEXT.
While the NEXT-Node TLV may contain basic values, it will contain a
set of nested level-2 TLVs.
Expires September 2001 [Page 10]
Internet Draft NEXT for OSPFv3 March, 2001
Only a single NEXT-Node TLV may be carried in an LSA.
The NEXT-Node TLV can be utilized to view OSPFv3 network entities
(i.e. routers) as devices with inherent states, separate from, but
similar to the way that links have been viewed traditionally.
Note that while NEXT-node TLVs are intended to add separate but
specific device information to the network topology, their
information may also be used as "macro" TLVs, adjusting the value of
interface TLVs. In this case, the Nodal TLVs can be viewed as
extended interface TLVs.
The architecture of the NEXT-Node 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 (15) | length (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Level2 TLVs |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The remainder of the NEXT-interface TLV is comprised of level-2 TLVs.
NEXT-Interface TLV Related level-2 TLVs
NEXT Interface Level-2 TLVs follow (and are part of) NEXT level-1
Interface TLVs in the NEXT-LSA. NEXT currently defines the following
level-2 TLVs for the Level-1 NEXT-Interface TLV:
Type Description
---------------------------------------------------
10 Link Type
15 Shared Risk Link Group
20 Administrative Metric
25 Bandwidth
30 Resource class/color
400-435 Reserved for IPv6 CoS (TBD)
Link Type level-2 TLV
The Link Type TLV identifies access characteristics of an interface.
This TLV appears as:
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 (10) | length |
Expires September 2001 [Page 11]
Internet Draft NEXT for OSPFv3 March, 2001
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The following values a currently defined for the link type attribute
of this TLV:
Type Description
---------------------------------------------------
10 Point-to-point
15 Multiaccess
Shared Risk Link Group Level-2 TLV
As in [6], the Shared Risk Link Group (SRLG) TLV permits the
advertisement and bonding of links to SRLGs. SRLGs are configured to
indicate the use of share resources whose failure may affect all
links in the set.
A link may belong to multiple SRLGs. Thus the SRLG TLV
describes a list of SRLGs that the link belongs to. An SRLG is
identified by a 32 bit number that is unique within an IGP domain
[6].
The value in the SRLG TLV is an unordered list of 32 bit numbers that
are the SRLGs that the link belongs to [6].
This TLV appears as:
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 (15) | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SRLG... |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Administrative Metric level-2 TLV
The Administrative Metric TLV specifies a supplemental interface
metric for network engineering purposes. This metric may be different
than the standard OSPF link metric, and should be considered with
greater significance. The default value should be zero (the lowest
metric).
This TLV appears as:
0 1 2 3
Expires September 2001 [Page 12]
Internet Draft NEXT for OSPFv3 March, 2001
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 (20) | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Administrative Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Bandwidth level-2 TLV
The Bandwidth Level-TLV specifies the overall (Total) outbound
interface bandwidth in IEEE floating point format. Whether this
metric should be automatically computed is TBD. To provide uniform
and eased network administration, the value of this TLV is specified
in kiloBITS per second.
When an OSPFv3 link is a MPLmS control channel as specified by Type
TLVs, the bandwidth should be the sum of the bandwidths of all
lambdas of all the fibers in the IP link at that priority level [6].
This TLV appears as:
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 (25) | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Resource Class/Color level-2 TLV
The Resource Class/Color sub-TLV specifies administrative group
membership for this link, in terms of a bit mask. A link that is a
member of multiple groups will have multiple bits set [3].
This TLV appears as:
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 (30) | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resource Class/Color Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NEXT-interface TLV related level-3 TLVs
NEXT Level-3 TLVs follow (and are part of) level-2 in NEXT-interface
level 2 TLVs. NEXT currently defines the following level-3 TLVs for
NEXT-interface Level-2 TLVs:
Expires September 2001 [Page 13]
Internet Draft NEXT for OSPFv3 March, 2001
Type Description Associated Level-2 TLV
---------------------------------------------------
10 Data Control Channel Link Type
Data Control Channel (DCC) level-3 TLV
The DCC TLV identifies A data control channel. An interface sending
this TLV is representing other, non OSPF interfaces in OSPF.
Furthermore, this TLV specifies whether other TLVs will represent all
non OSPF interfaces on this fiber as a single unit, or if all other
TLVs in the parent NEXT-Interface level-1 TLV refer to a specific non
OSPF channel. The second usage is useful when non OSPF channels have
differing states and capabilities.
The DCC interface will be identified by the physical interface ID
derived from the referenced router links LSA.
When the NEXT-Interface TLV is used to represent channels or lambdas
with differing state and capabilities interface index must be used
for identification.
This TLV appears as:
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 (10) | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|A|B| | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Non OSPF Interface Index |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The A bit when set, indicates that the parent NEXT-Interface TLV
represents a DCC, and that the values of all other TLVs in the NEXT-
Interface level-1 TLV refer to a conglomeration of the non OSPF
channels or lambdas.
The B bit when set, indicates that the parent NEXT-Interface TLV
represents a DCC, and that the values of all other TLVs are a
represent a SINGLE non OSPF channel or lambda. This non OSPF channel
or lambda is referenced by Non OSPF Interface Index.
NEXT-Node TLV related level-2 TLVs
NEXT-Node Level-2 TLVs follow (and are part of) NEXT-Node level-1
TLVs in the NEXT-LSA. NEXT currently defines the following level-2
TLVs for the NEXT-Node Level-1 TLV in the NEXT-LSA:
Type Description
---------------------------------------------------
Expires September 2001 [Page 14]
Internet Draft NEXT for OSPFv3 March, 2001
10 System Resource class/color
System Resource class/color level-2 TLV
The System Resource Class/Color sub-TLV specifies administrative
group membership for this system as a whole, in terms of a bit mask.
A system that is a member of multiple groups will have multiple bits
set [3]. This TLV overrides the system resource class/color assigned
to any interface.
This TLV appears as:
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 (10) | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Resource Class/Color Mask |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NEXT-Dynamic-LSA Related TLVs
This section provides information regarding TLVs which are only used
with the NEXT-Dynamic-LSA. NEXT-Dynamic-LSA related TLVs provide
state and capability data which is likely to change frequently.
NEXT-Dynamic-LSA level-1 TLVs
Level-1 TLVs follow the OSPFv3 LSA header. NEXT currently defines the
following level-1 TLVs:
Type Description
---------------------------------------------------
10 The NEXT-Dynamic-Interface TLV
15 The NEXT-Dynamic-Node TLV
The NEXT-Dynamic-Interface Level-1 TLV
The specifications of the NEXT-Dynamic-Interface TLV are the same as
those for the NEXT-Interface TLV (from the NEXT-LSA).
The NEXT-Dynamic-Node Level-1 TLV
The specifications of the NEXT-Dynamic-Node TLV are the same as those
for the NEXT-Interface TLV (from the NEXT-LSA).
NEXT-Dynamic-Interface TLV Related level-2 TLVs
NEXT Interface Level-2 TLVs follow (and are part of) NEXT level-1
Interface TLVs in the NEXT-Dynamic-LSA. NEXT currently defines the
Expires September 2001 [Page 15]
Internet Draft NEXT for OSPFv3 March, 2001
following level-2 TLVs for the Level-1 Interface TLV when viewed in
the NEXT-Dynamic-LSA:
Type Description
---------------------------------------------------
10 Unreserved Bandwidth
15 Delay Average
20 Reliability
25 Available Spectra
Unreserved Bandwidth level-2 TLV
The Unreserved Bandwidth level-2 TLV specifies the outbound interface
bandwidth not yet reserved in IEEE floating point format. Data
pertaining to class levels is TBD, however iterative issuance of
unreserved bandwidth TLVs per class may be possible by re-allocating
reserved bit space. The sum of each must be less than or equal to the
maximum reservable bandwidth. To provide uniform and eased network
administration, the value of this TLV is specified in KiloBITs per
second.
When an OSPFv3 link is a control channel representing a
conglomeration of non OSPF channels, as specified by the Link Type
TLV, the unreserved bandwidth should be the sum of the unused
bandwidths of all channels on all the links being represented at that
priority level allocated for reservation but not yet allocated [6].
This TLV appears as:
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 (10) | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Unreserved Bandwidth |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Delay Average level-2 TLV
The Delay Average TLV specifies the overall average (mean) outbound
delay in milliseconds. The Delay Average may be useful in situations
where path selection must be dependant on latency. This TLV may be
utilized when, for example the network contains slow or congested
links, or when traffic shaping is enabled. It would be beneficial to
calculate the delay automatically. A method for determining delay is
TBD, although one is presented in this document. Without an automatic
system for determining delay, it is possible to use a manual value.
Any automatic delay calculation system must balance granularity with
LSA origination rates; the delay average should be determined via an
Expires September 2001 [Page 16]
Internet Draft NEXT for OSPFv3 March, 2001
adjustable polling cycle. Special care must be taken to insure that
the received rate of LSAs generated due to this level-2 TLV is
sustainable.
This TLV should not be re-issued specifically due changes in the
polling average.
This TLV appears as:
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 (15) | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Polling Average | Delay Average |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Reliability level-2 TLV
The Reliability TLV specifies perceived interface reliability. This
TLV may provide a decay metric. This TLV may be useful in situations
where path selection must be dependant on:
-Loss
-Link technology fault tolerance (LTFT)
-Errors
The rate at which this TLV, and therefor an LSA is generated must
specifically be adjustable. Special care must be taken to insure that
the received rate of LSAs generated is sustainable. This TLV should
not be re-issued specifically due changes in the polling average.
Generation of this TLV to influence network topology may be governed
by mechanisms such as [13].
This TLV appears as:
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 (20) | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Reliability Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Available Spectra level-2 TLV
The available Spectra TLV specifies the number of lambdas that can
are unused and available on this interface. Additionally, this TLV
includes the wavelength range that is available. This TLV might be
used in conjunction with interfaces that specify the use control
Expires September 2001 [Page 17]
Internet Draft NEXT for OSPFv3 March, 2001
channels (i.e. links running OSPFv3 on a single connection, but layer
2 lambda switching on others). The specification of a control channel
is perform in a separate TLV. Wavelength is specified in nanometers,
and describes the starting or smallest wavelength for the channel.
This TLV appears as:
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 (25) | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|potential channel wavelength 1 |potential channel wavelength 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| . . . | . . . |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
NEXT-Dynamic-Node related level-2 TLVs
NEXT-Node Level-2 TLVs follow (and are part of) NEXT-Node level-1
TLVs in the NEXT-Dynamic-LSA. NEXT currently defines the following
level-2 TLVs for the NEXT-Node Level-1 TLV when contained in the
NEXT-Dynamic-LSA:
Type Description
---------------------------------------------------
10 System Error
System Error Level-2 TLV
The System Error TLV specifies the occurrence of a critical system
event, allowing that state to be injected into topology. This TLV
would be useful in situations where it would be beneficial to select
paths around compromised components. For example, this TLV might
allow paths to avoid a device with a failed cooling system. It would
be beneficial to send this TLV automatically. It may be possible to
send this TLV when system error SNMP traps are sent. To accomplish
this, a table listing general types of system errors and values could
be used to install value in this TLV. Thereafter, the value in the
TLV could be used to devalue other states and metrics, or it could be
used to effect topology directly. Any automatic system for issuing
this TLV must limit LSA origination rates. Special care must be taken
to insure that the received rate of LSAs generated due to this level-
2 TLV is sustainable.
This TLV should not be re-issued specifically due changes in the
polling average.
This TLV appears as:
Expires September 2001 [Page 18]
Internet Draft NEXT for OSPFv3 March, 2001
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 (10) | length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| System Error ID | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Acknowledgements
This document is based on "Traffic Engineering Extensions to OSPF" by
Katz, D., Yeung, D, and "Extensions to IS-IS/OSPF and RSVP
in support of MPL(ambda)S" by Kompella, K., Rekhter, Y., Awduche, D.,
Hannan, A., Hjalmtysson, G., Lawrence, J., Okamoto, S., Basak, D.,
Bernstein, G., Drake, J., Margalit, N., and Stern, E.
The Author acknowledges the following individuals:
-Alex Zinin, Cisco Systems
References
[1] Moy, J., "OSPF Version 2", RFC 2328, April 1998
[2] Coltun, R., Moy, J., "OSPF for IPv6" RFC 2740,
December 1999
[3] Katz, D., Yeung, D, "Traffic Engineering Extensions to OSPF",
internet Draft, April 2000
[4] Awduche, D., et al, "Requirements for Traffic Engineering Over
MPLS, work in progress.
[5] Luciani, J., Rajagopalan, B., Awduche, D., Cain, B., Jamoussi,
B., " IP over Optical Networks - A Framework", work in progress.
[6] Kompella, K., Rekhter, Y., Awduche, D., Hannan, A., Hjalmtysson,
G., Lawrence, J., Okamoto, S., Basak, D., Bernstein, G., Drake,
J., Margalit, N., Stern, E., "Extensions to IS-IS/OSPF and RSVP
in support of MPL(ambda)S", work in progress.
[7] Baker, F., and Coltun, R., "OSPF Version 2 Management
Information Base", RFC 1850, Cisco Systems, FORE Systems,
November 1995.
[8] Moy, J., "Multicast Extensions to OSPF", RFC 1584, Proteon,
Inc., September 1993.
[9] Carpenter, B. "Architectural Principles of the Internet", RFC
1958, June 1996
Expires September 2001 [Page 19]
Internet Draft NEXT for OSPFv3 March, 2001
[10] Giacalone, S., "Scored Fair Metric Calculation", Work in
Progress, July 2000.
[11] Christian, B., Davies, B., Tse, H., "Operational measurements
for traffic engineering", July 2000
[12] Awduche, D., Chiu, A., Elwalid, A., Widjaja, I., "A Framework
for Internet Traffic Engineering", July 2000.
[13] Giacalone, S., "OSPFv2 Metric Auto-Decay" Work in
Progress, August 2000
A Compatibility
Since NEXT uses new LSA/s, routers not running NEXT will simply
ignore and flood its messages. Additionally, NEXT uses OSPFv3
flooding scopes to limit its LSAs effect to areas of the network.
When a only subset of the devices in a network run NEXT, it should
still be possible to benefit from its use.
When routers run NEXT and are building separate topological databases
OSPFv3 will, generally, operate as when not running NEXT.
If NEXT is used to build composite metrics, the premise for path
selection may change greatly, as NEXT provides an abundance of new
information.
A.1 NEXT operation with resource class/color and COS
When enabled, NEXT advertises data for each class/color and/or COS on
a per interface/node basis. Put simply, each class/color and/or COS
can be viewed as another instance of an interface or node.
A.2 Basic Compatibility Criteria
To be compatible with this memo, NEXT implementations must support
the following minimum set of NEXT specifications:
-The NEXT-LSA
-The NEXT Interface Level-1 TLV
-NEXT Interface Level-2 TLVs
-Link type
-Link Media
-Shared Risk Link Group
-Administrative Metric
-Bandwidth
-Resource class/color
-The NEXT Node Level-1 TLV
-NEXT Node Level-2 TLVs
-System Resource class/color
Expires September 2001 [Page 20]
Internet Draft NEXT for OSPFv3 March, 2001
-The NEXT-Dynamic-LSA
-The NEXT-Dynamic-Interface level-1 TLV
-NEXT-Dynamic-Interface level-2 TLVs
-Unreserved Bandwidth
-Interface Delay Average
-The NEXT-Dynamic-Node level-1 TLV
-NEXT-Dynamic-Node level-2 TLVs
-System Error
A.3 Unnumbered Links
Since OSPFv3 separates network topology data and addressing
information advertisement, NEXT can operate on unnumbered links with
no additional implications. OSPFv3 refers to interfaces using network
protocol independent identifiers.
B NEXT State and the end-to-end argument
It appears that the end-to-end argument [9] does not apply to NEXT as
it is not an end-to-end protocol.
Furthermore, [9] specifies "that the network maintains some state
information: routes, QoS guarantees that it makes, session
information where that is used in header compression, compression
histories for data compression, and the like." Fortunately, NEXT
operates in the areas of routing, switching, and QoS and it therefor
operates within this specification.
While NEXT provides abundant state information to other intermediate
protocols (for example, MPLS) it makes efforts to minimize unneeded
information advertisement, and therefor complies with [9] in that the
volume of state data be minimized.
C Security Considerations
NEXT does not appear to provide risk in addition to that already
present in OSPF.
D Authors' Addresses
Spencer Giacalone
Predictive Systems, Inc.
25a Vreeland Road
Florham Park, NJ 07932
Phone: +1 (973) 301-5695
EMail: spencer.giacalone@predictive.com
E Full Copyright Statement
Expires September 2001 [Page 21]
Internet Draft NEXT for OSPFv3 March, 2001
Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Expires September 2001 [Page 22]