CCAMP Working Group D. Ceccarelli Internet-Draft D. Caviglia Intended status: Standards Track Ericsson Expires: April 18, 2011 S. Belotti P. Grandi Alcatel-Lucent F. Zhang D. Li Huawei Technologies J. Drake Juniper October 15, 2010 Technology Agnostic OSPF Traffic Engineering Extensions for Generalized MPLS (GMPLS) draft-bccdg-ccamp-gmpls-ospf-agnostic-00 Abstract This document defines a new approach to Generalized Multiprotocol Label Switching (GMPLS) bandwidth advertisement aiming at providing the Network Elements (NEs) and Path Computation Elements (PCEs) with all the data required for crank-backs minimization and scalability optimization. A new Open Shortest Path First - Traffic Engineering (OSPF-TE) routing protocol sub-tlv is defined for bandwidth advertisement per service type. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." This Internet-Draft will expire on April 18, 2011. Copyright Notice Ceccarelli, et al. Expires April 18, 2011 [Page 1] Internet-Draft Technology Agnostic OSPF-TE October 2010 Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 2. OSPF Extensions . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Bandwidth Accounting sub-TLV . . . . . . . . . . . . . . . 4 3. LSA composition . . . . . . . . . . . . . . . . . . . . . . . 8 4. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 5. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Compatibility Considerations . . . . . . . . . . . . . . . . . 16 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 9. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 11.1. Normative References . . . . . . . . . . . . . . . . . . . 17 11.2. Informative References . . . . . . . . . . . . . . . . . . 17 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 Ceccarelli, et al. Expires April 18, 2011 [Page 2] Internet-Draft Technology Agnostic OSPF-TE October 2010 1. Introduction An Opaque OSPF (Open Shortest Path First) LSA (Link State Advertisements) carrying application-specific information can be generated and advertised to other nodes following the flooding procedures defined in [RFC5250]. Three types of opaque LSA are defined, i.e. type 9 - link-local flooding scope, type 10 - area- local flooding scope, type 11 - AS flooding scope. Traffic Engineering (TE) LSA using type 10 opaque LSA is defined in [RFC3630] for TE purposes. This type of LSA is composed of a standard LSA header and a payload including one top-level TLV (Type/ Length/Value triplet) and possible several nested sub-TLVs. [RFC3630] defines two top-level TLVs: Router Address TLV and Link TLV; and nine possible sub-TLVs for the Link TLV, used to carry link related TE information. The Link type sub-TLVs are enhanced by [RFC4203] in order to support GMPLS networks and related specific link information. In GMPLS networks each node generates TE LSAs to advertise its TE information and capabilities (link-specific or node-specific), through the network. The TE information carried in the LSAs are collected by the other nodes of the network and stored into their local Traffic Engineering Databases (TED). In GMPLS networks, routing serves as the foundation for automatically establishing Label Switched Paths (LSPs) through GMPLS RSVP-TE signaling. This document describes technology agnostic OSPF LSA extensions to support connection oriented tranport networks under the control of GMPLS (e.g. OTN, SDH, MPLS-TP). In particular a new OSPF-TE LSP is defined for bandwidth advertisement per service type tanking into account priorities and technology specific capabilities. 1.1. Conventions Used in This Document 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 [RFC2119]. 2. OSPF Extensions Each TE LSA can carry a top-level link TLV with several nested sub- TLVs to describe different attributes of a TE link. Two top-level TLVs are defined in [RFC 3630]. (1) The Router Address TLV (referred Ceccarelli, et al. Expires April 18, 2011 [Page 3] Internet-Draft Technology Agnostic OSPF-TE October 2010 to as the Node TLV) and (2) the TE link TLV. One or more sub-TLVs can be nested into the two top-level TLVs. The sub-TLV set for the two top-level TLVs are also defined in [RFC 3630] and [RFC 4203]. This document defines a new link sub-TLV, called Bandwidth Accounting (BA) sub-TLV (Sub-tlv value TBA by IANA, suggested 26). One or more component links can be bundled as a TE link. In case of link bundling a single BA sub-TLV will be used to describe several component links. 2.1. Bandwidth Accounting sub-TLV The BA sub-TLV has a so generic format that it can be used for the advertisement of any type of transport technology, from SDH/SONET to OTN, from L2SC to PSC etc. The main difference from the ISCD defined in [RFC4202] is the fact that unreserved bandwidth is advertised per service type per priority. The format of the BA sub-TLV is based on "8 bytes" data blocks repeated for each service type/priority/ technology specific capability combination as is illustrated in Figure 1. Ceccarelli, et al. Expires April 18, 2011 [Page 4] Internet-Draft Technology Agnostic OSPF-TE October 2010 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Cap | Encoding | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Type | M | T.S. Flags | Reserved |Prior| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Type | M | T.S. Flags | Reserved |Prior| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Type | M | T.S. Flags | Reserved |Prior| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ~ ... ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Type | M | T.S. Flags | Reserved |Prior| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Bandwidth | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 1: Bandwidth Accounting sub-TLV format Where: o Switching Capability (8 bits): the values for this field are defined in [RFC4203] section 1.4. o Encoding (8 bits): the values for this field are defined in [RFC3471] section 3.1.1 and [RFC4328] section 3.1.1 - Data Blocks: Data blocks are composed by 64 bits and contain Service Type, M field, Technology Specific Flags, Priority and Bandwidth. For the definition of each field refer below. The number of data blocks depends on the number of service types, priority and technology specific features supported. Blocks declared in the LSA MUST contain a supported service type. Blocks declaring bandwidth at priority Pi, MUST NOT be declared in case priority Pi is not supported by the network element. Data blocks SHOULD be ordered from the highest to the lowest priority. If no priority is supported, just the 0 priority MUST be advertised. Please see the Example section for further details. o Service Type (8 bits): Indicates the type of service supported by Ceccarelli, et al. Expires April 18, 2011 [Page 5] Internet-Draft Technology Agnostic OSPF-TE October 2010 TE link (e.g. STMx in an SDH network, ODUx in an OTN network). Each Service Type in a TE-link can be advertised only once for each supported priority. o M field (2 bits): This field defines the meaning of the Bandwidth field. It states that the Bandwidth field is indicating Unreserved Bandwidth, Max LSP Bandwidth or Available Bandwidth. Possible values are: 0 - Unreserved bandwidth at priority Pi 1 - Max LSP bandwidth at priority Pi For the service types where the advertisement of more than one of the previous values needs to be advertised (e.g. OTN ODUflex, MPLS-TP interface), a data block for each value MUST be advertised. For example, when advertising an ODUflex service type in an OTN network, both Unreserved bandwidth and MAX LSDP bandwidth are advertised as illustrated in Figure 2 (assuming supported priorities: P1 and P5). [EDITOR NOTE]: Under Discussion - M=2 - Available bandwdith at priorioty Pi, Where Available bandwidth is defined as the unused link bandwidth available for additional non-traffic engineered IP/LDP forwarding and can be used as input to a node equal cost multipath load balancing function Ceccarelli, et al. Expires April 18, 2011 [Page 6] Internet-Draft Technology Agnostic OSPF-TE October 2010 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Cap | Encoding | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ODUflex |M=0| T.S. Flags | Reserved | P1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unreserved Bandwidth @ P1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ODUflex |M=1| T.S. Flags | Reserved | P1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth @ P1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ODUflex |M=0| T.S. Flags | Reserved | P5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unreserved Bandwidth @ P1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ODUflex |M=1| T.S. Flags | Reserved | P5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth @ P1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: M field utilization example o Technology Specific Flags (8 bits): These bits are used for the advertisement of technology specific interface capabilities and are defined in companion technology specific IDs. Depending on the technology it could be possible to have different data block advertised for different cabability flags. o Reserved (11 bits): Reserved bits MUST be set to zero. o Priority (3 bits): Indicates the priority related to the advertised service type. Only supported priorities MUST be advertised. o Bandwidth (32 bits): Independently on the type of bandwidth being advertised (see M field), this field is expressed in Bytes/sec in IEEE floating point format unless differently stated in technology specific documents. The maximum bandwidth that an LSP can occupy in a TE link is determined by the component link with the maximum unreserved bandwidth in such TE link. For example, if two OTN OTU3 component links are bundled in a TE link, the unreserved bandwidth of the first component link is 20*1.25 Gbps, and the unreserved bandwidth of the second component link is 24*1.25Gbps, then the unreserved bandwidth of this TE link is 44*1.25Gbps, but the maximum bandwidth an LSP can Ceccarelli, et al. Expires April 18, 2011 [Page 7] Internet-Draft Technology Agnostic OSPF-TE October 2010 occupy in this TE link is 24*1,25Gbps, not 44*1,25Gbps. All the reserved fields MUST be set to zero and SHOULD be ignored when received. 3. LSA composition Each NE generates an LSA to describe the attributes of each TE link. If we suppose to have unnumbered link IDs, the LSA should carry a link TLV with the following nested minimal sub-TLVs: < Link > ::= < Link Type > < Link ID > < Link Local/Remote Identifiers > < Generalized-ISCD > o Link Type sub-TLV: Defined in [RFC 3630]. o Link ID sub-TLV: Defined in [RFC 3630], for point-to-point link, indicates the remote router ID. o Link Local/Remote Identifiers sub-TLV: Defined in [RFC 4203], indicates the local link ID and the remote link ID. o Bandwidth Accounting sub-TLV: Defined in this document, carries the Bandwidth related information of the advertised TE-link. 4. Examples The examples in the following pages are not normative and are not intended to infer or mandate any specific implementation. Moreover they aim at giving a general idea of the utilization of the BA sub- TLV in a technology agnostic scenario. Figure 3 shows the case of a TE-link composed of two component links. +------+ component link 1 +------+ | +------------------+ | | N1 +------------------+ N2 | | | component link 2 | | +------+ +------+ Ceccarelli, et al. Expires April 18, 2011 [Page 8] Internet-Draft Technology Agnostic OSPF-TE October 2010 Figure 3: Example The nominal bandwidth of the two component links is 10Gbps and 40Gbps respectively. The former has the capability of carrying service types A and B, while the latter, service types B and C, where A and C are fixed bandwidth service types (just unreserved bandwidth is advertised) and B variable bandwidth service types (unreserved bandwidth and Max LSP bandwidth advertised). The supported priorities are:0 and 3. In this example the two component links are bundled as a TE link but it could also be possible to consider each of them as separate TE links. If the two component links are bundled together, N1 and N2 should assign a link local ID to the TE link and then N1 can get the link remote ID automatically or manually. Just after the creation of the TE Link comprising the two component links, the BA sub-TLV would be advertised as follows: Ceccarelli, et al. Expires April 18, 2011 [Page 9] Internet-Draft Technology Agnostic OSPF-TE October 2010 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Cap | Encoding | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S.Type(A) |M=0| T.S. Flags | Reserved | P0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unreserved Bandwidth = 10 Gbps | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S.Type(A) |M=0| T.S. Flags | Reserved | P3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unreserved Bandwidth = 10 Gbps | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S.Type(B) |M=0| T.S. Flags | Reserved | P0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unreserved Bandwidth = 50 Gbps | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S.Type(B) |M=1| T.S. Flags | Reserved | P0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth = 40 Gbps | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S.Type(B) |M=0| T.S. Flags | Reserved | P3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unreserved Bandwidth = 50 Gbps | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S.Type(B) |M=1| T.S. Flags | Reserved | P3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth = 40 Gbps | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S.Type(C) |M=0| T.S. Flags | Reserved | P0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unreserved Bandwidth = 40 Gbps | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S.Type(C) |M=0| T.S. Flags | Reserved | P3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unreserved Bandwidth = 40 Gbps | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Example - BA sub-TLV(to) Suppose that at time t1 an service type B LSP is created allocating 35 Gbps at priority 3. The BA sub-TLV will be modified as follows: Ceccarelli, et al. Expires April 18, 2011 [Page 10] Internet-Draft Technology Agnostic OSPF-TE October 2010 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Cap | Encoding | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S.Type(A) |M=0| T.S. Flags | Reserved | P0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unreserved Bandwidth = 10 Gbps | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S.Type(A) |M=0| T.S. Flags | Reserved | P3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unreserved Bandwidth = 10 Gbps | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S.Type(B) |M=0| T.S. Flags | Reserved | P0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unreserved Bandwidth = 50 Gbps | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S.Type(B) |M=1| T.S. Flags | Reserved | P0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth = 40 Gbps | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S.Type(B) |M=0| T.S. Flags | Reserved | P3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unreserved Bandwidth = 15 Gbps | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S.Type(B) |M=1| T.S. Flags | Reserved | P3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth = 10 Gbps | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S.Type(C) |M=0| T.S. Flags | Reserved | P0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unreserved Bandwidth = 40 Gbps | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S.Type(C) |M=0| T.S. Flags | Reserved | P3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unreserved Bandwidth = 5 Gbps | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Example - BA sub-TLV(t1) The last example shows how the prehemption is managed. In particular, if at time t2 a new 15 GBps service type B LSP with priority 0 is created, the LSP with priority 3 is pre-empted and its resources (or part of them) are allocated to the LSP with higher priority. The BA sub-TLV is updated accordingly to Figure 6: Ceccarelli, et al. Expires April 18, 2011 [Page 11] Internet-Draft Technology Agnostic OSPF-TE October 2010 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Cap | Encoding | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S.Type(A) |M=0| T.S. Flags | Reserved | P0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unreserved Bandwidth = 10 Gbps | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S.Type(A) |M=0| T.S. Flags | Reserved | P3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unreserved Bandwidth = 10 Gbps | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S.Type(B) |M=0| T.S. Flags | Reserved | P0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unreserved Bandwidth = 35 Gbps | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S.Type(B) |M=1| T.S. Flags | Reserved | P0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth = 25 Gbps | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S.Type(B) |M=0| T.S. Flags | Reserved | P3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unreserved Bandwidth = 35 Gbps | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S.Type(B) |M=1| T.S. Flags | Reserved | P3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth = 25 Gbps | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S.Type(C) |M=0| T.S. Flags | Reserved | P0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unreserved Bandwidth = 15 Gbps | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S.Type(C) |M=0| T.S. Flags | Reserved | P3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Unreserved Bandwidth = 15 Gbps | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Example - BA sub-TLV (t2) 5. Applicability The goal of this section is providing a comparison in term of bandwidth utilization between the BA sub-TLV based advertisement and the [RFC4203] based one. In order to provide a meaningful comparison between the two solutions (i.e. with same type and quantity of Ceccarelli, et al. Expires April 18, 2011 [Page 12] Internet-Draft Technology Agnostic OSPF-TE October 2010 information carried) it is necessary to assume [RFC4203] tools properly extended. In other words it is assumed that both unreserved bandwidth and max LSP bandwidth are advertised per signal type. The unreserved bandwidth per signal type could be advertised by means of an unreserved bandwidth sub-tlv per signal type (1 header word + 8 body words) or using the technology specific part of the ISCD (8 words). In this example the utilization of the technology specific part of the ISCD is considered in order to take into account the most optimized option. The following example is based on the advertisement of a simple link supporting six different types of fixed bandwidth service types (A,B,C,D,E,F) and a variable length service type (G). +------+ +------+ | | TE-link | | | N1 +------------------+ N2 | | | | | +------+ +------+ Figure 7: Example Three different cases are analyzed: - 8 priorities supported - 5 priorities supported - 1 priorities supported In the first case, [RFC4203] approach would use 1 ISCD per signal type. The ISCD would need to be extended as follows: Ceccarelli, et al. Expires April 18, 2011 [Page 13] Internet-Draft Technology Agnostic OSPF-TE October 2010 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Switching Cap | Encoding | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max LSP Bandwidth at priority 7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + | Technology Specific Part | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | S | Technology Specific Part | | W +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | I | Unreserved Bandwidth at priority 0 | | T +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C | Unreserved Bandwidth at priority 1 | | H. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Unreserved Bandwidth at priority 2 | | C +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | A | Unreserved Bandwidth at priority 3 | | P. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | Unreserved Bandwidth at priority 4 | | S +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | P | Unreserved Bandwidth at priority 5 | | E +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C. | Unreserved Bandwidth at priority 6 | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | I | Unreserved Bandwidth at priority 7 | | N +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + F. Figure 8: Example The amount of words used per ISCD is 20 for a total amount of 140 Ceccarelli, et al. Expires April 18, 2011 [Page 14] Internet-Draft Technology Agnostic OSPF-TE October 2010 words. On the other side, using the BA sub-TLV these words would be used: - 1 word for type/length declaration - 1 word for sub-tlv header - 2 words per (fixed) service type per priority = 2*6*8 = 96 - 4 words per (variable) service type per priority = 4*1*8 = 32 Total words used with 8 priorities: 140 (RFC4203) vs 130 (BA sub- TLV). Performing the same computation in a scenario where 5 priorities are supported, the number of words used in the [RFC4203] approach would be the same (140), while in the BA sub-TLV would be: - 1 word for type/length declaration - 1 word for sub-tlv header - 2 words per (fixed) service type per priority = 2*6*5 = 60 - 4 words per (variable) service type per priority = 4*1*5 = 20 Total words used with 5 priorities: 140 (RFC4203) vs 82 (BA sub-TLV). The difference is significantly higher as the number of supported priorities decreases. Considering the case of single priority, the number of words used by the BA sub-TLV approach would be: - 1 word for type/length declaration - 1 word for sub-tlv header - 2 words per (fixed) service type per priority = 2*6*1 = 12 - 4 words per (variable) service type per priority = 4*1*1 = 4 Total words used with 1 priority: 140 (RFC4203) vs 18 (BA sub-TLV). It is worth considering that using the Unreserved bandwdith sub-TLV for unreserved bandwidth advertisement would increase the difference between the two solutions due to the fact that a higher number of headers is needed and at least a new word per sub-TLV would be required for the identification of the service type. Ceccarelli, et al. Expires April 18, 2011 [Page 15] Internet-Draft Technology Agnostic OSPF-TE October 2010 6. Compatibility Considerations Backward compatibility issues are addressed in technology specific documents. 7. Security Considerations This document specifies the contents of Opaque LSAs in OSPFv2. As Opaque LSAs are not used for SPF computation or normal routing, the extensions specified here have no direct effect on IP routing. Tampering with GMPLS TE LSAs may have an effect on the underlying transport (optical and/or SONET-SDH) network. [RFC3630] suggests mechanisms such as [RFC2154] to protect the transmission of this information, and those or other mechanisms should be used to secure and/or authenticate the information carried in the Opaque LSAs. 8. IANA Considerations TBD 9. Contributors Francesco Fondelli, Ericsson Email: francesco.fondelli@ericsson.com Eve Varma, Alcatel-Lucent EMail: eve.varma@alcatel-lucent.com Jonathan Sadler, Tellabs EMail: Jonathan.Sadler@tellabs.com Lyndon Ong, Ciena EMail: Lyong@Ciena.com Ceccarelli, et al. Expires April 18, 2011 [Page 16] Internet-Draft Technology Agnostic OSPF-TE October 2010 10. Acknowledgements TBD 11. References 11.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2154] Murphy, S., Badger, M., and B. Wellington, "OSPF with Digital Signatures", RFC 2154, June 1997. [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998. [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005. [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005. [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The OSPF Opaque LSA Option", RFC 5250, July 2008. [RFC5339] Le Roux, JL. and D. Papadimitriou, "Evaluation of Existing GMPLS Protocols against Multi-Layer and Multi-Region Networks (MLN/MRN)", RFC 5339, September 2008. 11.2. Informative References Ceccarelli, et al. Expires April 18, 2011 [Page 17] Internet-Draft Technology Agnostic OSPF-TE October 2010 Authors' Addresses Daniele Ceccarelli Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy Email: daniele.ceccarelli@ericsson.com Diego Caviglia Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy Email: diego.caviglia@ericsson.com Sergio Belotti Alcatel-Lucent Via Trento, 30 Vimercate Italy Email: sergio.belotti@alcatel-lucent.com Pietro Vittorio Grandi Alcatel-Lucent Via Trento, 30 Vimercate Italy Email: pietro_vittorio.grandi@alcatel-lucent.com Fatai Zhang Huawei Technologies F3-5-B R&D Center, Huawei Base Shenzhen 518129 P.R.China Bantian, Longgang District Phone: +86-755-28972912 Email: zhangfatai@huawei.com Ceccarelli, et al. Expires April 18, 2011 [Page 18] Internet-Draft Technology Agnostic OSPF-TE October 2010 Dan Li Huawei Technologies F3-5-B R&D Center, Huawei Base Shenzhen 518129 P.R.China Bantian, Longgang District Phone: +86-755-28973237 Email: danli@huawei.com John E Drake Juniper Email: jdrake@juniper.net Ceccarelli, et al. Expires April 18, 2011 [Page 19]