CCAMP Working Group D. Ceccarelli Internet-Draft D. Caviglia Intended status: Standards Track Ericsson Expires: September 9, 2010 F. Zhang D. Li Huawei Technologies Y. Xu CATR March 8, 2010 Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolutive G.709 OTN Networks draft-ceccarelli-ccamp-gmpls-ospf-g709-01 Abstract Recent revisions of ITU-T Recommendation G.709 have introduced new features for OTNs:ODU0, ODU4, ODU2e, ODU3e1, ODU3e2 and ODUflex. The new features for the evolutive OTNs are described in separate ITU-T documents. ODU0, ODU2e and ODU4 ODUflex are described in [G709-V3]. ODU3e1 and ODU3e2 are described in [Gsup43]. This document describes OSPF routing protocol extensions to support the evolutive Optical Transport Networks (OTN) under the control of Generalized MPLS (GMPLS). Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and BCP 79. 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. This Internet-Draft will expire on September 9, 2010. Ceccarelli, et al. Expires September 9, 2010 [Page 1] Internet-Draft OSPF-TE extensions for OTN support March 2010 Copyright Notice 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 BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. OSPF Requirements . . . . . . . . . . . . . . . . . . . . . . 3 3. Overview of the Evolutive G.709 . . . . . . . . . . . . . . . 4 4. G.709 Digital Layer TE Information . . . . . . . . . . . . . . 6 4.1. Tributary Slot type . . . . . . . . . . . . . . . . . . . 6 4.2. TE link type . . . . . . . . . . . . . . . . . . . . . . . 7 4.3. LO ODU signal type . . . . . . . . . . . . . . . . . . . . 7 4.4. TE link Unreserved Bandwidth . . . . . . . . . . . . . . . 8 4.5. Maximum LSP Bandwidth . . . . . . . . . . . . . . . . . . 8 5. OSPF Extensions . . . . . . . . . . . . . . . . . . . . . . . 8 5.1. OTN Interface Switching Capability Descriptor . . . . . . 9 6. Compatibility Considerations . . . . . . . . . . . . . . . . . 11 7. Example . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 12.1. Normative References . . . . . . . . . . . . . . . . . . . 18 12.2. Informative References . . . . . . . . . . . . . . . . . . 18 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 Ceccarelli, et al. Expires September 9, 2010 [Page 2] Internet-Draft OSPF-TE extensions for OTN support March 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 purpose. 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 the GMPLS based G.709 Optical Transport Networks (OTNs), in order to automatically establish ODUk connections through GMPLS RSVP-TE signaling, routing is the foundation. OTN networks provide flexible and various multiplexing relationships (e.g., ODUj multiplexed into ODUk (j j) signal can be depicted as follows: - ODU0 into ODU1 multiplexing (with 1,25Gbps TS granularity) - ODU0, ODU1, ODUflex into ODU2 multiplexing (with 1.25Gbps TS granularity) - ODU1 into ODU2 multiplexing (with 2.5Gbps TS granularity) - ODU0, ODU1, ODU2, ODU2e and ODUflex into ODU3 multiplexing (with 1.25Gbps TS granularity) - ODU1, ODU2 into ODU3 multiplexing (with 2.5Gbps TS granularity) - ODU0, ODU1, ODU2, ODU2e, ODU3 and ODUflex into ODU4 multiplexing (with 1.25Gbps TS granularity) - ODU2e into ODU3e1 multiplexing (with 2.5Gbps TS granularity) - ODU2e into ODU3e2 multiplexing (with 1.25Gbps TS granularity) Ceccarelli, et al. Expires September 9, 2010 [Page 5] Internet-Draft OSPF-TE extensions for OTN support March 2010 In order to be backward compatible with the 2.5Gbps TS defined in [G709-V3], both the 2.5Gbps TS and the 1.25Gbps TS can be used in the two cases listed below: o ODU1 into ODU2 multiplexing o ODU1 and ODU2 into ODU3 multiplexing From the link perspective, it can only work under one TS type. For example, if the both ends (or interfaces) of the link can support 2.5Gbps TS and 1.25Gbps TS, then it can work under 2.5Gbps TS or 1.25Gbps TS. If one end can support 1.25Gbps TS, and another end can support 2.5Gbps TS, the end with 1.25Gbps TS MUST adopt a 2.5Gbps TS). 4. G.709 Digital Layer TE Information This document only considers the TE information needed for LO ODU path computation. WSON TE information is out of scope. Please refer to [WSON-OSPF] for more information about WSON routing information. From the perspective of [G709-V3], there are two different cases for LO ODU: (1) A LO ODUk mapped into an OTUk. In this case, the server layer of this LO ODU is an OTUk. For example, if a STM-16 signal is encapsulated into an ODU1 and then mapped into OTU1, the ODU1 is a LO ODU. (2) A LO ODUj multiplexed into a HO (Higher Order) ODUk (j < k) occupying several TSs. In this case, the server layer of this LO ODU is a HO ODUk. For example, if an ODU1 is multiplexed into ODU2 and then mapped into an OTU2, the ODU1 is a LO ODU and the ODU2 is a HO ODU. In order to compute a suitable path the PCE (centralized or distributed) needs a set of data that should be advertised by the routing protocol. In the following sections each type of data is listed and analyzed, while the possible values are shown in section 5. 4.1. Tributary Slot type ITU-T recommendations define two types of TS but, from the link perspective, it can only work under one of them. For example, if the both ends (or interfaces) of a link can support 2.5Gbps TS or 1.25Gbps TS, then the link will work under 2.5Gbps TS or 1.25Gbps TS. Ceccarelli, et al. Expires September 9, 2010 [Page 6] Internet-Draft OSPF-TE extensions for OTN support March 2010 If one end can support the 1.25Gbps TS, and another end the 2.5Gbps TS, the former end SHOULD adopt the 2.5Gbps TS. In addition, the bandwidth accounting depends on the type of TS. Therefore, the type of the TS should be known during LO ODU path computation. 4.2. TE link type The link type indicates the OTUk/HO ODUk type of the TE link. The TS bandwidth of different types of OTUk is different; it increases along with the increasing of k (see [G709-V3]). The bandwidth of a TS in a TE link can be deduced from the TS type and link type of the TE link. For example, the bandwidth of a 1.25G TS without NJO (Negative Justification Opportunity) in an OTU2 is about 1.249409620 Gbps, while the bandwidth of a 1.25G TS without NJO in an OTU3 is about 1.254703729 Gbps. The actual TS bandwidth of a TE link is useful to determine the number of TSs needed by an ODUflex service. And the actual TS bandwidth of a TE link can be deduced by the TE link type and TS type. 4.3. LO ODU signal type It is possible that some equipments can not support all the LO ODU signal types. When a path computation procedure for a LO ODU is performed, it needs to check whether a link has the capability to carry a specific type of LO ODU or not. If a link can not carry this type of LO ODU, it should be excluded during the path computation. Only the links with the capability of carrying this type of LO ODU can be the candidates. For example, in the following figure, the interfaces IF1, IF2, IF8, IF7, IF5 and IF6 can support ODUflex signals, while the interfaces IF3 and IF4 cannot. In this case, if one ODUflex connection from A to C is requested, link #1 and #2 are excluded and link #3 and link #4 are the candidates (the possible path could be A-D-C through link #3 and link #4). Ceccarelli, et al. Expires September 9, 2010 [Page 7] Internet-Draft OSPF-TE extensions for OTN support March 2010 +-----+ link #3 | | link #4 +-----------------+ D +-----------------+ | IF8| |IF7 | | +-----+ | | | |IF1 IF6| +--+--+ +-----+ +--+--+ | | link #1 | | link #2 | | | A +--------------+ B +--------------+ C | | |IF2 IF3| |IF4 IF5| | +-----+ +-----+ +-----+ Figure 1: LO ODU signal type Therefore, it is necessary to advertise the LO ODU types that the OTU or HO ODU TE link can support. 4.4. TE link Unreserved Bandwidth In the GMPLS based OTN networks, the Unreserved Bandwidth of a TE link is the sum of the unreserved bandwidths of all the component links associated with the bundled link. The unreserved bandwidth can be accounted through the unallocated Tributary Slots of the TE link. 4.5. Maximum LSP Bandwidth 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 OTU3 component links are bundled to a TE link, the unreserved bandwidth of the first component link is 20*1.25G TSs, and the unreserved bandwidth of the second component link is 24*1.25G TSs. Then the unreserved bandwidth of this TE link is 44*1.25G TSs, but the maximum TSs that a LSP can occupy in this TE link is 24, not 44. 5. OSPF Extensions In terms of GMPLS based OTN networks, each OTUk/HO ODUk can be viewed as a component link, and each component link can carry one or more types of LO ODU. Ceccarelli, et al. Expires September 9, 2010 [Page 8] Internet-Draft OSPF-TE extensions for OTN support March 2010 Each TE LSA can carry a top-level 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 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]. A general Interface Switching Capability Descriptor (ISCD) sub-TLV is defined In [RFC 4203]. The bandwidth accounting is encoded in a 4 octets field in the IEEE floating point format. Max LSP Bandwidth is accounted at each priority X (0~7). This document defines a new sub-TLV of the Link TLV, called OTN Interface Switching Capability Descriptor (OTN-ISCD) with value TBD by IANA. The OTN-ISCD format is described in Section 5.1. One or more component links can be bundled as a TE link. In case of link bundling an OTN-ISCD will be used for each component link. 5.1. OTN Interface Switching Capability Descriptor The format of the new OTN-Interface Switching Capability Descriptor is defined in Figure 2. Ceccarelli, et al. Expires September 9, 2010 [Page 9] Internet-Draft OSPF-TE extensions for OTN support March 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Res| T |OD(T)Uk| Reserved | Signal Flags |G|F|E|D|C|B|A| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P0 | Unreserved TS at p0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P1 | Unreserved TS at p1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P2 | Unreserved TS at p2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P3 | Unreserved TS at p3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P4 | Unreserved TS at p4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P5 | Unreserved TS at p5 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P6 | Unreserved TS at p6 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P7 | Unreserved TS at p7 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: OTN-Interface Switching Capability Descriptor Where: o T (2 bits): Indicates the type of the Tributary Slot of this TE link, value 0 means the TS type is 1.25Gbps, value 1 means the TS type is 2.5Gbps. o OD(T)Uk (4 bits): Indicates the type of the TE link, i.e. the server layer signal that the LO ODUs can be mapped or multiplexed into. The following values are defined: 0: Reserved (for future use) 1: OTU1/HO ODU1 2: OTU2/HO ODU2 3: OTU3/HO ODU3 4: OTU4/HO ODU4 Ceccarelli, et al. Expires September 9, 2010 [Page 10] Internet-Draft OSPF-TE extensions for OTN support March 2010 5: OTU2e/HO ODU2e 6-15: Reserved (for future use) The bandwidth of a TS in this TE link can be deduced from T bit and OD(T)Uk field. o Signal Flags (16 bits): This field indicates the LO ODU type supported by the TE link. A flag set to 1 indicates that the TE link supports the corresponding LO ODU signal. Currently the following flags are defined: Flag A: indicates whether LO ODU0 is supported. Flag B: indicates whether LO ODU1 is supported. Flag C: indicates whether LO ODU2 is supported. Flag D: indicates whether LO ODU3 is supported. Flag E: indicates whether LO ODU4 is supported. Flag F: indicates whether LO ODU2e is supported. Flag G: indicates whether LO ODUflex is supported. Other bits are reserved and must be set to zero when sent and should be ignored when received. o Max lsp TS at Pi (16 bits): Indicates the maximum number of unreserved TS at priority Pi of all of the component links of the TE link. o Unreserved TS at Pi (12 bits): Indicates the number of unreserved TSs at priority Pi inside all the component links of the TE link. All the reserved fields must be set to zero and should be ignored when received. 6. Compatibility Considerations The legacy nodes that do not implement the extensions defined in this document are able to ignore the LSA containing an OTN-ISCD sub-TLV. They will continue to flood the LSA to other neighbors, but will not use the information carried in this LSA. Ceccarelli, et al. Expires September 9, 2010 [Page 11] Internet-Draft OSPF-TE extensions for OTN support March 2010 7. Example Based on the sub-TLVs defined in [RFC 3630], [RFC 4203] and this document, a G.709 digital TE link can be described as follows. +------+ component link 1 +------+ | +------------------+ | | N1 +------------------+ N2 | | | component link 2 | | +--+---+ +---+--+ Figure 3: Example This picture shows a simple example of an OTN network. The link type of the two component links are OTU2 and OTU3 respectively. The former have the capability of carrying ODU0, ODU1 and ODUflex client signals, while the latter, ODU1, ODU2, ODU3 and ODUflex. The TS type is 1.25Gbps and all the possible priorities are supported (0~7). The two component links can be bundled as a TE link but it is also possible to consider each of them as a separate TE link. If the two component links are bundled together, N1 and N2 should assign a link local ID to the TE link and then N1 get the link remote ID automatically or manually. N1 can generate an LSA to describe the above attributes of the TE link. Suppose the link IDs are unnumbered, the LSA should carry a link TLV with the following nested minimal sub-TLVs: < G.709 Digital Link > ::= < Link Type > < Link ID > < Link Local/Remote Identifiers > < OTN Interface Switching Capability Descriptor > o Link Type sub-TLV: Defined in [RFC 3630], G.709 digital links are always type 1 - Point-to-point link. 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. Ceccarelli, et al. Expires September 9, 2010 [Page 12] Internet-Draft OSPF-TE extensions for OTN support March 2010 o OTN Interface Switching Capability Descriptor sub-TLV: Defined in this document, carries the characteristic of this G.709 digital TE link. Just after the creation of the TE Link comprising the two component links, the two ISCDs would be 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Res|T=0|OTk =2 | Reserved | Signal Flags |1|0|0|0|0|1|1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P0 =8 | Unreserved TS at p0 =8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P1 =8 | Unreserved TS at p1 =8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P2 =8 | Unreserved TS at p2 =8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P3 =8 | Unreserved TS at p3 =8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P4 =8 | Unreserved TS at p4 =8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P5 =8 | Unreserved TS at p5 =8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P6 =8 | Unreserved TS at p6 =8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P7 =8 | Unreserved TS at p7 =8 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 4: Example - OTN-ISCD OTU2 LC (to) Ceccarelli, et al. Expires September 9, 2010 [Page 13] Internet-Draft OSPF-TE extensions for OTN support March 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Res|T=0|OTk =3 | Reserved | Signal Flags |1|0|0|1|1|1|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P0 =32 | Unreserved TS at p0 =32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P1 =32 | Unreserved TS at p1 =32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P2 =32 | Unreserved TS at p2 =32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P3 =32 | Unreserved TS at p3 =32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P4 =32 | Unreserved TS at p4 =32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P5 =32 | Unreserved TS at p5 =32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P6 =32 | Unreserved TS at p6 =32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P7 =32 | Unreserved TS at p7 =32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 5: Example - OTN-ISCD OTU3 LC (to) Suppose that at time t1 an LSP is created allocating 35 Gbps at priority 3. The OTN-ISCD referring to the OTU2 component link is unmodified (Figure 4 and the OTN-ISCD referring to the OTU3 component link is modified as illustrated in Figure 6): Ceccarelli, et al. Expires September 9, 2010 [Page 14] Internet-Draft OSPF-TE extensions for OTN support March 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Res|T=0|OTk =3 | Reserved | Signal Flags |1|0|0|1|1|1|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P0 =32 | Unreserved TS at p0 =32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P1 =32 | Unreserved TS at p1 =32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P2 =32 | Unreserved TS at p2 =32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P3 =4 | Unreserved TS at p3 =4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P4 =4 | Unreserved TS at p4 =4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P5 =4 | Unreserved TS at p5 =4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P6 =4 | Unreserved TS at p6 =4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P7 =4 | Unreserved TS at p7 =4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 6: Example - OTN-ISCD OTU3 LC (t1) The last example shows how the prehemption is managed. In particular, if a time t2 a new 15 GBps LSP with priority 1 is created, the LSP with priority 3 is prehempted and its resouces (or part of them) are allocated to the LSP with higher priority. The OTN-ISCD sub-TLV related to component link 2 is updated accordingly to Figure 7: Ceccarelli, et al. Expires September 9, 2010 [Page 15] Internet-Draft OSPF-TE extensions for OTN support March 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Res|T=0|OTk =3 | Reserved | Signal Flags |1|0|0|1|1|1|0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P0 =32 | Unreserved TS at p0 =32 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P1 =20 | Unreserved TS at p1 =20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P2 =20 | Unreserved TS at p2 =20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P3 =20 | Unreserved TS at p3 =20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P4 =20 | Unreserved TS at p4 =20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P5 =20 | Unreserved TS at p5 =20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P6 =20 | Unreserved TS at p6 =20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Max lsp TS at P7 =20 | Unreserved TS at p7 =20 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 7: Example - OTN-ISCD OTU3 LC (t2) 8. 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. 9. IANA Considerations TBD 10. Contributors Ceccarelli, et al. Expires September 9, 2010 [Page 16] Internet-Draft OSPF-TE extensions for OTN support March 2010 Xiaobing Zi Huawei Technologies F3-5-B R&D Center, Huawei Base Bantian, Longgang District Shenzhen 518129 P.R.China Email: zixiaobing@huawei.com Francesco Fondelli Ericsson Via Negrone 1/A Genova - 16145 Email: francesco.fondelli@ericsson.com Marco Corsi Altran Italia Via Negrone 1/A Genova - 16145 EMail: marco.corsi@altran.it 11. Acknowledgements The authors would like to thank Eric Gray for his precious comments and advices. 12. References Ceccarelli, et al. Expires September 9, 2010 [Page 17] Internet-Draft OSPF-TE extensions for OTN support March 2010 12.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. [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. 12.2. Informative References [G.709] ITU-T, "Interface for the Optical Transport Network (OTN)", G.709 Recommendation (and Amendment 1), February 2001. [G.709-v3] ITU-T, "Draft revised G.709, version 3", consented by ITU-T on Oct 2009. [Gsup43] ITU-T, "Proposed revision of G.sup43 (for agreement)", December 2008. Ceccarelli, et al. Expires September 9, 2010 [Page 18] Internet-Draft OSPF-TE extensions for OTN support March 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 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 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 Yunbin Xu CATR 11 Yue Tan Nan Jie Beijing P.R.China Email: xuyunbin@mail.ritt.com.cn Ceccarelli, et al. Expires September 9, 2010 [Page 19]