Re: OSPFv2 Opaque LSAs in OSPFv3
"Manral, Vishwas" <VishwasM@NETPLANE.COM> Wed, 09 October 2002 10:19 UTC
Received: from cherry.ease.lsoft.com (cherry.ease.lsoft.com [209.119.0.109]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id GAA08666 for <ospf-archive@LISTS.IETF.ORG>; Wed, 9 Oct 2002 06:19:03 -0400 (EDT)
Received: from walnut (209.119.0.61) by cherry.ease.lsoft.com (LSMTP for Digital Unix v1.1b) with SMTP id <18.0076166F@cherry.ease.lsoft.com>; Wed, 9 Oct 2002 6:21:07 -0400
Received: from DISCUSS.MICROSOFT.COM by DISCUSS.MICROSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 270463 for OSPF@DISCUSS.MICROSOFT.COM; Wed, 9 Oct 2002 06:21:07 -0400
Received: from 12.27.183.253 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0f) with TCP; Wed, 9 Oct 2002 06:21:07 -0400
Received: by XOVER.dedham.mindspeed.com with Internet Mail Service (5.5.2653.19) id <4B0H3N31>; Wed, 9 Oct 2002 06:21:06 -0400
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain; charset="iso-8859-1"
Message-ID: <E7E13AAF2F3ED41197C100508BD6A3287917BD@india_exch.hyderabad.mindspeed.com>
Date: Wed, 09 Oct 2002 06:23:23 -0400
Reply-To: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
Sender: Mailing List <OSPF@DISCUSS.MICROSOFT.COM>
From: "Manral, Vishwas" <VishwasM@NETPLANE.COM>
Subject: Re: OSPFv2 Opaque LSAs in OSPFv3
To: OSPF@DISCUSS.MICROSOFT.COM
Precedence: list
One small correction Link-ID sub TLV length would always be 4-bytes i.e. Interface ID or Router Id of neigbor. Thanks, Vishwas -----Original Message----- From: Manral, Vishwas [mailto:VishwasM@NETPLANE.COM] Sent: Wednesday, October 09, 2002 3:43 PM To: OSPF@DISCUSS.MICROSOFT.COM Subject: Re: OSPFv2 Opaque LSAs in OSPFv3 Hi Acee/folks, > Completely agree. Could you put this in draft form? This is at least > the second time the question of opaque LSAs and OSPFv3 has been raised. Ok just to start to get the ball rolling, I am attaching a rip-off of the Katz Yeung draft for OSPFv3. The main points are : - a) New LSA type defined b) U-bit set to 0 c) Whereever IP address was used, has been changed. I guess we can do with reference to the Katz-yeung draft and other TE drafts. However for now I have left stuff as it is. Kireeti/Kunihiro or anyone else willing to help please let me know. Thanks, Vishwas ========================================================= Network Working Group Vishwas Manral Internet Draft Netplane Systems Category: Standards Track October 2002 Expires: March 2003 draft-manral-ospfv3-traffic-00.txt Traffic Engineering Extensions to OSPF Version 3 *** Draft *** Status 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. Copyright Notice Copyright (C) The Internet Society (2002). All Rights Reserved. Abstract This document describes extensions to the OSPF protocol version 3 to support intra-area Traffic Engineering, using a new OSPFv3 [RFC2740] LSA type called Intra-Area-TE-LSA. 1. Introduction This document specifies a method of adding traffic engineering capabilities to OSPF Version 3 [1]. The architecture of traffic engineering is described in [2]. The semantic content of the extensions is essentially identical to the corresponding extensions to IS-IS and OSPFv2[katz-yeung-draft]. It is expected that the traffic engineering extensions to OSPFv3 will continue to mirror those in OSPFv2. The extensions provide a way of describing the traffic engineering topology (including bandwidth and administrative constraints) and distributing this information within a given OSPFv3 area. This topology does not necessarily match the regular routed topology, though this proposal depends on Network LSAs to describe multi-access links. 1.1. Applicability Many of the extensions specified in this document are in response to the requirements stated in [2], and thus are referred to as "traffic engineering extensions", and are also commonly associated with MPLS Traffic Engineering. A more accurate (albeit bland) designation is "extended link attributes", as what is proposed is simply to add more attributes to links in OSPFv3 advertisements. The information made available by these extensions can be used to build an extended link state database just as router LSAs are used to build a "regular" link state database; the difference is that the extended link state database (referred to below as the traffic engineering database) has additional link attributes. Uses of the traffic engineering database include: o monitoring the extended link attributes; o local constraint-based source routing; and o global traffic engineering. For example, an OSPFv3-speaking device can participate in an OSPFv3 area, build a traffic engineering database, and thereby report on the reservation state of links in that area. In "local constraint-based source routing", a router R can compute a path from a source node A to a destination node B; typically, A is R itself, and B is specified by a "router address" (see below). This path may be subject to various constraints on the attributes of the links and nodes that the path traverses, e.g., use green links that have unreserved bandwidth of at least 10Mbps. This path could then be used to carry some subset of the traffic from A to B, forming a simple but effective means of traffic engineering. How the subset of traffic is determined, and how the path is instantiated is beyond the scope of this document; suffice it to say that one means of defining the subset of traffic is "those packets whose IP destinations were learned from B", and one means of instantiating paths is using MPLS tunnels. As an aside, note that constraint-based routing can be NP- hard, or even unsolvable, depending on the nature of the attributes and constraints and thus many implementations will use heuristics. Consequently, we don't attempt to sketch an algorithm here. Finally, for "global traffic engineering", a device can build a traffic engineering database, input a traffic matrix and an optimization function, crunch on the information, and thus compute optimal or near-optimal routing for the entire network. The device can subsequently monitor the traffic engineering topology and react to changes by recomputing the optimal routes. 1.2. Limitations As mentioned above, this document specifies extensions and procedures for intra-area distribution of Traffic Engineering information. Methods for inter-area and inter-AS (Autonomous System) are not discussed here. The extensions specified in this document capture the reservation state of point-to-point links. The reservation state of multiaccess links is not accurately reflected, except in the special case that there are only two devices in the multiaccess subnetwork. This document also does not support unnumbered links. This deficiency is addressed in [4]; see also [5] and [6]. 1.3. Conventions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [7]. 2. LSA Format 2.1. LSA type This extension makes use of a new OSPFv3 LSA type called Intra-Area-TE-LSA. The LSA function code of which is 10 and the LSA type value is 0x200a. The U-bit of the LSA has been set to 0. This helps prevent flooding of Intra-Area-TE-LSA's to other routers within the area which do not support the LSA type. 2.2. LSA ID The LSA ID field is used to identify different Intra-Area-TE-LSA's. A maximum of 4294967296 Traffic Engineering LSAs may be sourced by a single system. The LSA ID has no topological significance. 2.3. LSA Format Overview 2.3.1. LSA Header The Traffic Engineering LSA starts with the standard LSA header. The values of the fields of significance in the header have been defined above. 2.3.2. TLV Header The LSA payload consists of one or more nested Type/Length/Value (TLV) triplets for extensibility. The format of each TLV is: 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Value... | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Length field defines the length of the value portion in octets (thus a TLV with no value portion would have a length of zero). The TLV is padded to four-octet alignment; padding is not included in the length field (so a three octet value would have a length of three, but the total size of the TLV would be eight octets). Nested TLVs are also 32-bit aligned. Unrecognized types are ignored. This memo defines Types 1 and 2. See the IANA Considerations section for allocation of new Types. 2.4. LSA payload details An LSA contains one top-level TLV. There are two top-level TLVs defined: 1 - Router Address 2 - Link 2.4.1. Router Address TLV The Router Address TLV specifies a stable IP address of the advertising router that is always reachable if there is any connectivity to it. This is typically implemented as a "loopback address"; the key attribute is that the address does not become unusable if an interface is down. In other protocols this is known as the "router ID," but for obvious reasons this nomenclature is avoided here. If a router advertises BGP routes with the BGP next hop attribute set to the BGP router ID, then the Router Address SHOULD be the same as the BGP router ID. If IS-IS is also active in the domain, this address can also be used to compute the mapping between the OSPFv3 and IS-IS topologies. For example, suppose a router R is advertising both IS-IS and OSPF Traffic Engineering LSAs, and suppose further that some router S is building a single Traffic Engineering Database (TED) based on both IS-IS and OSPFv3 TE information. R may then appear as two separate nodes in S's TED; however, if both the IS-IS and OSPFv3 LSAs generated by R contain the same Router Address, then S can determine that the IS-IS TE LSA and the OSPFv3 TE LSA from R are indeed from a single router. The router address TLV is type 1, and has a length of 16, and the value is the sixteen octet IPv6 address. It must appear in exactly one Traffic Engineering LSA originated by a router. The address used cannot be a link-local address. 2.4.2. Link TLV The Link TLV describes a single link. It is constructed of a set of sub-TLVs. There are no ordering requirements for the sub-TLVs. Only one Link TLV shall be carried in each LSA, allowing for fine granularity changes in topology. The Link TLV is type 2, and the length is variable. The following sub-TLVs are defined: 1 - Link type (1 octet) 2 - Link ID (variable octets) 5 - Traffic engineering metric (4 octets) 6 - Maximum bandwidth (4 octets) 7 - Maximum reservable bandwidth (4 octets) 8 - Unreserved bandwidth (32 octets) 9 - Administrative group (4 octets) 103 - Local interface IP address (16N octets) 104 - Remote interface IP address (16N octets) This memo defines sub-Types for OSPFv3. See the IANA Considerations section for allocation of new sub-Types. The Link Type and Link ID sub-TLVs are mandatory, i.e., must appear exactly once. All other sub-TLVs defined here may occur at most once. These restrictions need not apply to future sub-TLVs. Unrecognized sub-TLVs are ignored. Various values below use the (32 bit) IEEE Floating Point format. For quick reference, this format is as follows: 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |S| Exponent | Fraction | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ where S is the sign; Exponent is the exponent base 2 in "excess 127" notation; and Fraction is the mantissa - 1, with an implied binary point in front of it. Thus the above represents the value (-1)**(S) * 2**(Exponent-127) * (1 + Fraction) For more details, refer to [9]. 2.5. Sub-TLV Details 2.5.1. Link Type The Link Type sub-TLV defines the type of the link: 1 - Point-to-point 2 - Multiaccess The Link Type sub-TLV is TLV type 1, and is one octet in length. 2.5.2. Link ID The Link ID sub-TLV identifies the other end of the link. For point- to-point links, this is the Router ID of the neighbor. For multiaccess links, this is the interface ID of the designated router. The Link ID sub-TLV is TLV type 2, and is four or 16 octets octets in Length, depending on the link type. 2.5.3. Local Interface IP Address The Local Interface IP Address sub-TLV specifies the IP address(es) of the interface corresponding to this link. If there are multiple local addresses on the link, they are all listed in this sub-TLV. Are we required to advertise the Link-local-Addresses too.(I guess not) The Local Interface IP Address sub-TLV is TLV type 3, and is 16N octets in length, where N is the number of local addresses. 2.5.4. Remote Interface IP Address The Remote Interface IP Address sub-TLV specifies the IP address(es) of the neighbor's interface corresponding to this link. This and the local address are used to discern multiple parallel links between systems. If the Link Type of the link is Multiaccess, the Remote Interface IP Addess is set to 0.0.0.0 . The Remote Interface IP Address sub-TLV is TLV type 4, and is 16N octets in length, where N is the number of neighbor IPv6 addresses. 2.5.5. Traffic Engineering Metric The Traffic Engineering Metric sub-TLV specifies the link metric for traffic engineering purposes. This metric may be different than the standard OSPF link metric. Typically, this metric is assigned by a network admistrator. The Traffic Engineering Metric sub-TLV is TLV type 5, and is four octets in length. 2.5.6. Maximum Bandwidth The Maximum Bandwidth sub-TLV specifies the maximum bandwidth that can be used on this link in this direction (from the system originating the LSA to its neighbor), in IEEE floating point format. This is the true link capacity. The units are bytes per second. The Maximum Bandwidth sub-TLV is TLV type 6, and is four octets in 2.5.7. Maximum Reservable Bandwidth The Maximum Reservable Bandwidth sub-TLV specifies the maximum bandwidth that may be reserved on this link in this direction, in IEEE floating point format. Note that this may be greater than the maximum bandwidth (in which case the link may be oversubscribed). This SHOULD be user-configurable; the default value should be the Maximum Bandwidth. The units are bytes per second. The Maximum Reservable Bandwidth sub-TLV is TLV type 7, and is four octets in length. 2.5.8. Unreserved Bandwidth The Unreserved Bandwidth sub-TLV specifies the amount of bandwidth not yet reserved at each of the eight priority levels, in IEEE floating point format. The values correspond to the bandwidth that can be reserved with a setup priority of 0 through 7, arranged in increasing order with priority 0 occurring at the start of the sub- TLV, and priority 7 at the end of the sub-TLV. The initial values (before any bandwidth is reserved) are all set to the Maximum Reservable Bandwidth. Each value will be less than or equal to the Maximum Reservable Bandwidth. The units are bytes per second. The Unreserved Bandwidth sub-TLV is TLV type 8, and is 32 octets in length. 2.5.9. Administrative Group The Administrative Group sub-TLV contains a 4-octet bit mask assigned by the network administrator. Each set bit corresponds to one administrative group assigned to the interface. A link may belong to multiple groups. By convention the least significant bit is referred to as 'group 0', and the most significant bit is referred to as 'group 31'. The Administrative Group is also called Resource Class/Color [2]. The Administrative Group sub-TLV is TLV type 9, and is four octets in length. 3. Elements of Procedure Routers shall originate Traffic Engineering LSAs whenever the LSA contents change, and whenever otherwise required by OSPF (an LSA refresh, for example). Note that this does not mean that every change must be flooded immediately; an implementation MAY set thresholds (for example, a bandwidth change threshold) that trigger immediate flooding, and initiate flooding of other changes after a short time interval. In any case, the origination of Traffic Engineering LSAs SHOULD be rate-limited to at most one every MinLSInterval [1]. Upon receipt of a changed Traffic Engineering LSA or Network LSA (since these are used in traffic engineering calculations), the router should update its traffic engineering database. No SPF or other route calculations are necessary. 4. Compatibility Issues There should be no interoperability issues with routers that do not implement these extensions. OSPFv3 [RFC2740] already defines ways to handle unknown LSA types. As the U-bit is not set the LSA is treated as a Link-Local LSA by a router which does not understand the LSA type. The result of having routers that do not implement these extensions is that the traffic engineering topology will be missing pieces; however, if the topology is connected, TE paths can still be calculated and ought to work. 5. Normative References 6. Informative References 7. Security Considerations This document specifies the contents of Intr-Area-TE LSAs in OSPFv3. As the LSA's are not used for SPF computation or normal routing, the extensions specified here have no affect on IP routing. Tampering with TE LSAs may have an effect on traffic engineering computations, however, and it is suggested that whatever mechanisms are used for securing the transmission of normal OSPFv3 LSAs be applied equally to all TE LSA's. 8. IANA Considerations 9. Authors' Addresses Vishwas Manral Netplane Systems, 189, Prashasan Nagar, Road Number 72, Jubilee Hills, Hyderabad - 33 INDIA 10. IPR Notices 11. Full Copyright Notice Copyright (C) The Internet Society (2002). 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 implmentation 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.
- OSPFv2 Opaque LSAs in OSPFv3 Kireeti Kompella
- Re: OSPFv2 Opaque LSAs in OSPFv3 Alex Zinin
- Re: OSPFv2 Opaque LSAs in OSPFv3 Kireeti Kompella
- Re: OSPFv2 Opaque LSAs in OSPFv3 Kunihiro Ishiguro
- Re: OSPFv2 Opaque LSAs in OSPFv3 Kireeti Kompella
- Re: OSPFv2 Opaque LSAs in OSPFv3 Acee Lindem
- Re: OSPFv2 Opaque LSAs in OSPFv3 Kunihiro Ishiguro
- Re: OSPFv2 Opaque LSAs in OSPFv3 Kireeti Kompella
- Re: OSPFv2 Opaque LSAs in OSPFv3 Manral, Vishwas
- Re: OSPFv2 Opaque LSAs in OSPFv3 Manral, Vishwas
- Re: OSPFv2 Opaque LSAs in OSPFv3 Acee Lindem
- Re: OSPFv2 Opaque LSAs in OSPFv3 Acee Lindem
- Re: OSPFv2 Opaque LSAs in OSPFv3 Kireeti Kompella
- Re: OSPFv2 Opaque LSAs in OSPFv3 Kunihiro Ishiguro
- Re: OSPFv2 Opaque LSAs in OSPFv3 Kireeti Kompella
- Re: OSPFv2 Opaque LSAs in OSPFv3 Kunihiro Ishiguro
- Re: OSPFv2 Opaque LSAs in OSPFv3 Kireeti Kompella
- Re: OSPFv2 Opaque LSAs in OSPFv3 Kireeti Kompella
- Re: OSPFv2 Opaque LSAs in OSPFv3 Manral, Vishwas
- Re: OSPFv2 Opaque LSAs in OSPFv3 Acee Lindem
- Re: OSPFv2 Opaque LSAs in OSPFv3 Manral, Vishwas
- Re: OSPFv2 Opaque LSAs in OSPFv3 Kireeti Kompella
- Re: OSPFv2 Opaque LSAs in OSPFv3 Alex Zinin
- Re: OSPFv2 Opaque LSAs in OSPFv3 Kireeti Kompella
- Re: OSPFv2 Opaque LSAs in OSPFv3 Alex Zinin
- Re: OSPFv2 Opaque LSAs in OSPFv3 Kunihiro Ishiguro
- Re: OSPFv2 Opaque LSAs in OSPFv3 Padma Pillay-Esnault
- Re: OSPFv2 Opaque LSAs in OSPFv3 Kireeti Kompella
- Re: OSPFv2 Opaque LSAs in OSPFv3 Manral, Vishwas
- Re: OSPFv2 Opaque LSAs in OSPFv3 Manral, Vishwas
- Re: OSPFv2 Opaque LSAs in OSPFv3 Manral, Vishwas
- Re: OSPFv2 Opaque LSAs in OSPFv3 Kunihiro Ishiguro
- Re: OSPFv2 Opaque LSAs in OSPFv3 Kunihiro Ishiguro
- Re: OSPFv2 Opaque LSAs in OSPFv3 Manral, Vishwas
- OSPFv3 Intra area prefix LSA Suvani Kaura
- Re: OSPFv2 Opaque LSAs in OSPFv3 Kireeti Kompella
- Re: OSPFv2 Opaque LSAs in OSPFv3 Kireeti Kompella
- Re: OSPFv3 Intra area prefix LSA Yasuhiro Ohara
- Re: OSPFv3 Intra area prefix LSA Sina Mirtorabi
- Re: OSPFv2 Opaque LSAs in OSPFv3 Manral, Vishwas
- Re: OSPFv2 Opaque LSAs in OSPFv3 Kunihiro Ishiguro
- Re: OSPFv2 Opaque LSAs in OSPFv3 Naidu, Venkata
- Re: OSPFv2 Opaque LSAs in OSPFv3 Kireeti Kompella
- Re: OSPFv2 Opaque LSAs in OSPFv3 Alex Zinin
- Re: OSPFv2 Opaque LSAs in OSPFv3 Alex Zinin
- Re: OSPFv2 Opaque LSAs in OSPFv3 Dennis Ferguson
- Re: OSPFv2 Opaque LSAs in OSPFv3 Naidu, Venkata
- Re: OSPFv2 Opaque LSAs in OSPFv3 Manral, Vishwas
- Re: OSPFv2 Opaque LSAs in OSPFv3 Alex Zinin
- Re: OSPFv2 Opaque LSAs in OSPFv3 Alex Zinin
- Re: OSPFv2 Opaque LSAs in OSPFv3 Bill Fenner
- Re: OSPFv2 Opaque LSAs in OSPFv3 Acee Lindem
- Re: OSPFv2 Opaque LSAs in OSPFv3 Sina Mirtorabi
- Re: OSPFv2 Opaque LSAs in OSPFv3 Dennis Ferguson
- Re: OSPFv2 Opaque LSAs in OSPFv3 Tony Przygienda
- Re: OSPFv2 Opaque LSAs in OSPFv3 Sina Mirtorabi
- Re: OSPFv2 Opaque LSAs in OSPFv3 Erblichs