CCAMP Working Group S. Belotti, Ed. Internet-Draft P. Grandi Intended status: Informational Alcatel-Lucent Expires: December 27, 2013 D. Ceccarelli, Ed. D. Caviglia Ericsson F. Zhang D. Li Huawei Technologies June 25, 2013 Evaluation of existing GMPLS encoding against G.709v3 Optical Transport Networks (OTN) draft-ietf-ccamp-otn-g709-info-model-09 Abstract ITU-T recommendation G.709 [G.709-2012] has introduced new fixed and flexible Optical Data Unit (ODU) containers in Optical Transport Networks (OTNs). This document provides an evaluation of existing Generalized Multiprotocol Label Switching (GMPLS) routing and signaling protocols against the G.709 [G.709-2012] OTN networks. 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 December 27, 2013. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. Belotti, et al. Expires December 27, 2013 [Page 1] Internet-Draft GMPLS evaluation against G.709v3 OTN June 2013 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 2. G.709 Mapping and Multiplexing Capabilities . . . . . . . . . 3 3. Tributary Slot Granularity . . . . . . . . . . . . . . . . . . 6 3.1. Data Plane Considerations . . . . . . . . . . . . . . . . 6 3.1.1. Payload Type and TS granularity relationship . . . . . 6 3.1.2. Fall-back procedure . . . . . . . . . . . . . . . . . 8 3.2. Control Plane considerations . . . . . . . . . . . . . . . 8 4. Tributary Port Number . . . . . . . . . . . . . . . . . . . . 12 5. Signal type . . . . . . . . . . . . . . . . . . . . . . . . . 12 6. Bit rate and tolerance . . . . . . . . . . . . . . . . . . . . 14 7. Unreserved Resources . . . . . . . . . . . . . . . . . . . . . 14 8. Maximum LSP Bandwidth . . . . . . . . . . . . . . . . . . . . 14 9. Distinction between terminating and switching capability . . . 15 10. Priority Support . . . . . . . . . . . . . . . . . . . . . . . 17 11. Multi-stage multiplexing . . . . . . . . . . . . . . . . . . . 17 12. Generalized Label . . . . . . . . . . . . . . . . . . . . . . 18 13. Security Considerations . . . . . . . . . . . . . . . . . . . 18 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 15. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 19 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 17.1. Normative References . . . . . . . . . . . . . . . . . . . 20 17.2. Informative References . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Belotti, et al. Expires December 27, 2013 [Page 2] Internet-Draft GMPLS evaluation against G.709v3 OTN June 2013 1. Introduction GMPLS routing and signaling, as defined by [RFC4203], [RFC3473] and [RFC4328], provides the mechanisms for basic GMPLS control of OTN networks based on the 2001 revision of the G.709 specification. The 2012 revision of the G.709 specification, [G.709-2012], includes new OTN features which are not supported by GMPLS. This document provides an evaluation of exiting GMPLS signaling and routing protocols against G.709 [G.709-2012] requirements. Background information and a framework for the GMPLS protocol extensions need to support [G.709-2012] is provided in [OTN-FWK]. Specific routing and signaling extensions are defined in [OTN-OSPF] and [OTN-RSVP]. 2. G.709 Mapping and Multiplexing Capabilities The digital OTN layered structure is comprised of digital path layer (ODU) and digital section layer (OTU). An OTU (Optical Transport Unit) section layer supports one ODU path layer as client and provides monitoring capability for the OCh. An ODU path layer may transport a heterogeneous assembly of ODU clients. Some types of ODUs (i.e., ODU1, ODU2, ODU3, ODU4) may assume either a client or server role within the context of a particular networking domain. ITU-T G.872 recommendation [G.872] provides two tables defining mapping and multiplexing capabilities of OTNs, which are reported below. Belotti, et al. Expires December 27, 2013 [Page 3] Internet-Draft GMPLS evaluation against G.709v3 OTN June 2013 +--------------------+--------------------+ | ODU client | OTU server | +--------------------+--------------------+ | ODU 0 | - | +--------------------+--------------------+ | ODU 1 | OTU 1 | +--------------------+--------------------+ | ODU 2 | OTU 2 | +--------------------+--------------------+ | ODU 2e | - | +--------------------+--------------------+ | ODU 3 | OTU 3 | +--------------------+--------------------+ | ODU 4 | OTU 4 | +--------------------+--------------------+ | ODU flex | - | +--------------------+--------------------+ Figure 1: OTN mapping capability Belotti, et al. Expires December 27, 2013 [Page 4] Internet-Draft GMPLS evaluation against G.709v3 OTN June 2013 +=================================+=========================+ | ODU client | ODU server | +---------------------------------+-------------------------+ | 1.25 Gbps client | | +---------------------------------+ ODU 0 | | - | | +=================================+=========================+ | 2.5 Gbps client | | +---------------------------------+ ODU 1 | | ODU 0 | | +=================================+=========================+ | 10 Gbps client | | +---------------------------------+ ODU 2 | | ODU0,ODU1,ODUflex | | +=================================+=========================+ | 10.3125 Gbps client | | +---------------------------------+ ODU 2e | | - | | +=================================+=========================+ | 40 Gbps client | | +---------------------------------+ ODU 3 | | ODU0,ODU1,ODU2,ODU2e,ODUflex | | +=================================+=========================+ | 100 Gbps client | | +---------------------------------+ ODU 4 | |ODU0,ODU1,ODU2,ODU2e,ODU3,ODUflex| | +=================================+=========================+ |CBR clients from greater than | | |2.5 Gbit/s to 100 Gbit/s: or | | |GFP-F mapped packet clients from | ODUflex | |1.25 Gbit/s to 100 Gbit/s. | | +---------------------------------+ | | - | | +=================================+=========================+ Figure 2: OTN multiplexing capability How an ODUk connection service is transported within an operator network is governed by operator policy. For example, the ODUk connection service might be transported over an ODUk path over an OTUk section, with the path and section being at the same rate as that of the connection service (see Table 1). In this case, an entire lambda of capacity is consumed in transporting the ODUk connection service. On the other hand, the operator might exploit different multiplexing capabilities in the network to improve infrastructure efficiencies within any given networking domain. In Belotti, et al. Expires December 27, 2013 [Page 5] Internet-Draft GMPLS evaluation against G.709v3 OTN June 2013 this case, ODUk multiplexing may be performed prior to transport over various rate ODU servers (as per Table 2) over associated OTU sections. From the perspective of multiplexing relationships, a given ODUk may play different roles as it traverses various networking domains. As detailed in [OTN-FWK], client ODUk connection services can be transported over: o Case A) one or more wavelength sub-networks connected by optical links or o Case B) one or more ODU links (having sub-lambda and/or lambda bandwidth granularity) o Case C) a mix of ODU links and wavelength sub-networks. This document considers the TE information needed for ODU path computation and parameters needed to be signaled for LSP setup. The following sections list and analyze, for each type of data that needs to be advertised and signaled, what is already there in GMPLS and what is missing. 3. Tributary Slot Granularity ITU-T recommendation defines two types of Tributary Slot (TS) granularity. This TS granularity is defined per layer, meaning that both ends of a link can select proper TS granularity differently for each supported layer, based on the rules below: - If both ends of a link are new cards supporting both 1.25Gbps TS and 2.5Gbps TS, then the link will work with 1.25Gbps TS. - If one end is a new card supporting both the 1.25Gbps and 2.5Gbps TS granularities, and the other end is an old card supporting just the 2.5Gbps TS granularity, the link will work with 2.5Gbps TS granularity. 3.1. Data Plane Considerations 3.1.1. Payload Type and TS granularity relationship As defined in G.709-2012 an ODUk container consist of an Optical Payload Unit (OPUk) plus a specific ODUk Overhead (OH). OPUk OH information is added to the OPUk information payload to create an Belotti, et al. Expires December 27, 2013 [Page 6] Internet-Draft GMPLS evaluation against G.709v3 OTN June 2013 OPUk. It includes information to support the adaptation of client signals. Within the OPUk overhead there is the payload structure identifier (PSI) that includes the payload type (PT). The payload type (PT) is used to indicate the composition of the OPUk signal. When an ODUj signal is multiplexed into an ODUk, the ODUj signal is first extended with frame alignment overhead and then mapped into an Optical channel Data Tributary Unit (ODTU). Two different types of ODTU are defined: - ODTUjk ((j,k) = {(0,1), (1,2), (1,3), (2,3)}; ODTU01, ODTU12, ODTU13 and ODTU23) in which an ODUj signal is mapped via the Asynchronous Mapping Procedure (AMP), defined in clause 19.5 of G.709-2012. - ODTUk.ts ((k,ts) = (2,1..8), (3,1..32), (4,1..80)) in which a lower order ODU (ODU0, ODU1, ODU2, ODU2e, ODU3, ODUflex) signal is mapped via the Generic Mapping Procedure (GMP), defined in clause 19.6 of G.709-2012. G.709-2012 introduces also a logical entity, called Optical Data Tributary Unit Group (ODTUGk), characterizing the multiplexing of the various ODTU. The ODTUGk is then mapped into OPUK. ODTUjk and ODTUk.ts signals are directly time-division multiplexed into the tributary slots of an HO OPUk. When PT is assuming value 0x20 or 0x21,together with OPUk type (K= 1,2,3,4), it is used to discriminate two different ODU multiplex structure ODTUGx : - Value 0x20: supporting ODTUjk only, - Value 0x21: supporting ODTUk.ts or ODTUk.ts and ODTUjk. The distinction is needed for OPUk with K =2 or 3, since OPU2 and OPU3 are able to support both the different ODU multiplex structures. For OPU4 and OPU1, only one type of ODTUG is supported: ODTUG4 with PT=0x21 and ODTUG1 with PT=0x20. (see table Figure 6).The relationship between PT and TS granularity, is in the fact that the two different ODTUGk discriminated by PT and OPUk are characterized by two different TS granularities of the related OPUk, the former at 2.5Gbps, the latter at 1.25Gbps. In order to complete the picture, in the PSI OH there is also the Multiplex Structure Identifier (MSI) that provides the information on which tributary slots the different ODTUjk or ODTUk.ts are mapped into the related OPUk. The following figure shows how the client traffic is multiplexed till the OPUk layer. Belotti, et al. Expires December 27, 2013 [Page 7] Internet-Draft GMPLS evaluation against G.709v3 OTN June 2013 +--------+ +------------+ +----+ | !------| ODTUjk |-----Client | | | ODTUGk | +-----.------+ | |-----| PT=0x21| . | | | | +-----.------+ | | | |------| ODTUk.TS |-----Client |OPUk| +--------+ +------------+ | | | | +--------+ +------------+ | | | |------| ODTUjk |-----Client | |-----| | +-----.------+ +----+ | ODTUGk | . | PT=0x20| +-----.------+ | |------| ODTUjk |-----Client +--------+ +------------+ Figure 3: OTN client multiplexing 3.1.2. Fall-back procedure ITU-T G.798 [G.798] describes the so called PT=0x21-to-PT=0x20 interworking process that explains how two nodes with interfaces with different PayloadType, and hence different TS granularity (1.25Gbps vs. 2.5Gbps), can be coordinated so to permit the equipment with 1.25 TS granularity to adapt his TS allocation accordingly to the different TS granularity (2.5Gbps) of a neighbor. Therefore, in order to let the NE change TS granularity accordingly to the neighbor requirements, the AUTOpayloadtype [G.798] needs to be set. When both the neighbors (link or trail) have been configured as structured, the payload type received in the overhead is compared to the transmitted PT. If they are different and the transmitted PT=0x21, the node must fallback to PT=0x20. In this case the fallback process makes the system self-consistent and the only reason for signaling the TS granularity is to provide the correct label (i.e. label for PT=0x21 has twice the TS number of PT=0x20). On the other side, if the AUTOpayloadtype is not configured, the RSVP-TE consequent actions in case of TS mismatch need to be defined. 3.2. Control Plane considerations When setting up an ODUj over an ODUk, it is possible to identify two types of TS granularity, the server and the client one. The server TS granularity is used to map an end to end ODUj onto a server ODUk LSP or links. This parameter cannot be influenced in any way from the ODUj LSP: ODUj LSP will be mapped on tributary slots available on the different links/ODUk LSPs. When setting up an ODUj at a given Belotti, et al. Expires December 27, 2013 [Page 8] Internet-Draft GMPLS evaluation against G.709v3 OTN June 2013 rate, the fact that it is carried over a path composed by links/ Forwarding Adjacencies(FAs) structured with 1.25Gbps or 2.5Gbps TS granularity is completely transparent to the end to end ODUj. The client TS granularity information is one of the parameters needed to correctly select the adaptation towards the client layers at the end nodes and this is the only thing that the ODUj has to guarantee. In figure 4 an example of client and server TS granularity utilization in a scenario with mixed [RFC4328] OTN and [G.709-2012] OTN interfaces is shown. ODU1-LSP ......................................... TSG-C| |TSG-C 1.25| ODU2-H-LSP |1.25 +------------X--------------------------+ | TSG-S| |TSG-S | 2.5| |2.5 | | ODU3-H-LSP | | |------------X-------------| | | | +--+--+ +--+--+ +---+-+ | | | | +-+ +-+ | | | A +------+ B +-----+ +***+ +-----+ Z | | V.3 | OTU2 | V.1 |OTU3 +-+ +-+ OTU3| V.3 | +-----+ +-----+ +-----+ ... Service LSP --- H-LSP Figure 4: Client-Server TS granularity example In this scenario, an ODU3 LSP is setup from node B to Z. Node B has an old interface able to support 2.5Gbps TS granularity, hence only client TS granularity equal to 2.5Gbps can be exported to ODU3 H-LSP possible clients. An ODU2 LSP is setup from node A to node Z with client TS granularity 1.25Gbps signaled and exported towards clients. The ODU2 LSP is carried by ODU3 H-LSP from B to Z. Due to the limitations of old node B interface, the ODU2 LSP is mapped with 2.5Gbps TS granularity over the ODU3 H-LSP. Then an ODU1 LSP is setup from A to Z, carried by the ODU2 H-LSP and mapped over it using a 1.25Gbps TS granularity. What is shown in the example is that the TS granularity processing is a per layer issue: even if the ODU3 H-LSP is created with TS Belotti, et al. Expires December 27, 2013 [Page 9] Internet-Draft GMPLS evaluation against G.709v3 OTN June 2013 granularity client at 2.5Gbps, the ODU2 H-LSP must guarantee a 1.25Gbps TS granularity client. ODU3 H-LSP is eligible from ODU2 LSP perspective since from the routing it is known that this ODU3 interface at node Z, supports an ODU2 termination exporting a TS granularity 1.25Gbps/2.5Gbps. The TS granularity information is needed in the routing protocol as the ingress node (A in the previous example) needs to know if the interfaces at the last hop can support the required TS granularity. In case they cannot, A will compute an alternate path from itself to Z (see figure 4). Moreover, also TS granularity information needs to be signaled. Consider as example the setup of an ODU3 forwarding adjacency that is going to carry an ODU0, hence the support of 1.25Gbps TS is needed. The information related to the TS granularity has to be carried in the signaling to permit node C (see figure 5) choose the right one among the different interfaces (with different TS granularitys) towards D. In case the full ERO is provided in the signaling with explicit interface declaration, there is no need for C to choose the right interface towards D as it has been already decided by the ingress node or by the PCE. ODU3 <----------------------> ODU0 <--------------------------------------> | | +--------+ +--------+ +--------+ +--------+ | | | | | | 1.25 | | | Node | | Node | | Node +------+ Node | | A +------+ B +------+ C | ODU3 | D | | | ODU3 | | ODU3 | +------+ | +--------+ 1.25 +--------+ 2.5 +--------+ 2.5 +--------+ Figure 5: TS granularity in signaling In case an ODUk FA_LSP needs to be set up nesting another ODUj (as depicted in figure 5), there might be the need to know the hierarchy of nested LSPs in addition to TS granularity, to permit the penultimate hop (i.e. C) choosing the correct interface towards the egress node or any intermediate node (i.e. B) choosing the right path when performing ERO expansion. This is not needed in case we allow bundling only component links with homogeneous hierarchies. In case of specific implementation not specifying in the ERO the last Belotti, et al. Expires December 27, 2013 [Page 10] Internet-Draft GMPLS evaluation against G.709v3 OTN June 2013 hop interface, crank-back can be a solution. In a multi-stage multiplexing environment any layer can have a different TS granularity structure, e.g. in a multiplexing hierarchy such as ODU0->ODU2->ODU3, the ODU3 can be structured at TS granularity=2.5Gbps in order to support an ODU2 connection, but this ODU2 connection can be a tunnel for ODU0, and hence structured with 1.25Gbps TS granularity. Therefore any multiplexing level has to advertise its TS granularity capabilities in order to allow a correct path computation by the end nodes (both of the ODUk trail and of the H-LSP/FA). The following table shows the different mapping possibilities depending on the TS granularity types. The client types are shown in the left column, while the different OPUk server and related TS granularities are listed in the top row. The table also shows the relationship between the TS granularity and the payload type. +------------------------------------------------+ | 2.5G TS || 1.25G TS | | OPU2 | OPU3 || OPU1 | OPU2 | OPU3 | OPU4 | +-------+------------------------------------------------+ | | - | - || AMP | GMP | GMP | GMP | | ODU0 | | ||PT=0x20|PT=0x21|PT=0x21|PT=0x21| +-------+------------------------------------------------+ | | AMP | AMP || - | AMP | AMP | GMP | | ODU1 |PT=0x20|PT=0x20|| |PT=0x21|PT=0x21|PT=0x21| +-------+------------------------------------------------+ | | - | AMP || - | - | AMP | GMP | | ODU2 | |PT=0x20|| | |PT=0x21|PT=0x21| +-------+------------------------------------------------+ | | - | - || - | - | GMP | GMP | | ODU2e | | || | |PT=0x21|PT=0x21| +-------+------------------------------------------------+ | | - | - || - | - | - | GMP | | ODU3 | | || | | |PT=0x21| +-------+------------------------------------------------+ | | - | - || - | GMP | GMP | GMP | | ODUfl | | || |PT=0x21|PT=0x21|PT=0x21| +-------+------------------------------------------------+ Figure 6: ODUj into OPUk mapping types (Source: Table 7-10 [G.709- 2012]) Specific information could be defined in order to carry the multiplexing hierarchy and adaptation information (i.e. TS Belotti, et al. Expires December 27, 2013 [Page 11] Internet-Draft GMPLS evaluation against G.709v3 OTN June 2013 granularity/PT, AMP/GMP) to enable precise path selection. In this way, when the penultimate node (or the intermediate node performing ERO expansion) receives such object, together with the Traffic Parameters Object, it is possible to choose the correct interface towards the egress node. In conclusion both routing and signaling needs to be extended to appropriately represent the TS granularity/PT information. Routing needs to represent a link's TS granularity and PT capabilities as well as the supported multiplexing hierarchy. Signaling needs to represent the TS granularity/PT and multiplexing hierarchy encoding. 4. Tributary Port Number [RFC4328] supports only the deprecated auto-MSI mode which assumes that the Tributary Port Number is automatically assigned in the transmit direction and not checked in the receive direction. As described in [G.709-2012] and [G.798], the OPUk overhead in an OTUk frame contains n (n = the total number of TSs of the ODUk) MSI (Multiplex Structure Identifier) bytes (in the form of multi-frame), each of which is used to indicate the association between tributary port number and tributary slot of the ODUk. The association between TPN and TS has to be configured by the control plane and checked by the data plane on each side of the link. (Please refer to [OTN-FWK] for further details). As a consequence, the RSVP-TE signaling needs to be extended to support the TPN assignment function. 5. Signal type From a routing perspective, [RFC4203] allows advertising [RFC4328] interfaces (single TS type) without the capability of providing precise information about bandwidth specific allocation. For example, in case of link bundling, dividing the unreserved bandwidth by the MAX LSP bandwidth it is not possible to know the exact number of LSPs at MAX LSP bandwidth size that can be set up. (see example fig. 3) The lack of spatial allocation heavily impacts the restoration process, because the lack of information of free resources highly increases the number of crank-backs affecting network convergence time. Moreover actual tools provided by [RFC4203] only allow advertising Belotti, et al. Expires December 27, 2013 [Page 12] Internet-Draft GMPLS evaluation against G.709v3 OTN June 2013 signal types with fixed bandwidth and implicit hierarchy (e.g. SDH/ SONET networks) or variable bandwidth with no hierarchy (e.g. packet switching networks) but do not provide the means for advertising networks with mixed approach (e.g. ODUflex CBR and ODUflex packet). For example, advertising ODU0 as MIN LSP bandwidth and ODU4 as MAX LSP bandwidth it is not possible to state whether the advertised link supports ODU4 and ODUflex or ODU4, ODU3, ODU2, ODU1, ODU0 and ODUflex. Such ambiguity is not present in SDH networks where the hierarchy is implicit and flexible containers like ODUFlex do not exist. The issue could be resolved by declaring 1 ISCD for each signal type actually supported by the link. Supposing for example to have an equivalent ODU2 unreserved bandwidth in a TE-link (with bundling capability) distributed on 4 ODU1, it would be advertised via the ISCD in this way: MAX LSP Bw: ODU1 MIN LSP Bw: ODU1 - Maximum Reservable Bandwidth (of the bundle) set to ODU2 - Unreserved Bandwidth (of the bundle) set to ODU2 In conclusion, the OSPF-TE extensions defined in [RFC4203] require a different ISCD per signal type in order to advertise each supported container. This motivates attempting to look for a more optimized solution, without proliferations of the number of ISCD advertised. Per [RFC2328], OSPF messages are directly encapsulated in IP datagrams and depend on IP fragmentation when transmitting packets larger than the network MTU. [RFC2328] recommends that "IP fragmentation should be avoided whenever possible." This recommendation further constraints solutions as OSPF does not support any generic mechanism to fragment OSPF LSAs. With respect to link bundling [RFC4201], the utilization of the ISCD as it is, would not allow precise advertising of spatial bandwidth allocation information unless using only one component link per TE link. On the other hand, from a signaling point of view, [RFC4328] describes GMPLS signaling extensions to support the control for pre- G.709-2012 OTNs. However, [RFC4328] needs to be updated because it does not provide the means to signal all the new signal types and related mapping and multiplexing functionalities. Belotti, et al. Expires December 27, 2013 [Page 13] Internet-Draft GMPLS evaluation against G.709v3 OTN June 2013 6. Bit rate and tolerance In the current traffic parameters signaling, bit rate and tolerance are implicitly defined by the signal type. ODUflex CBR and Packet can have variable bit rates(please refer to [OTN-FWK] table 2); hence signaling traffic parameters need to be upgraded. With respect to the tolerance there is no need to upgrade GMPLS protocols as a fixed value (+/-100 ppm or +/-20ppm depending on the signal type) is defined for each signal type. 7. Unreserved Resources Unreserved resources need to be advertised per priority and per signal type in order to allow the correct functioning of the restoration process. [RFC4203] only allows advertising unreserved resources per priority, this leads not to know how many LSPs of a specific signal type can be restored. As example it is possible to consider the scenario depicted in the following figure. +------+ component link 1 +------+ | +------------------+ | | | component link 2 | | | N1 +------------------+ N2 | | | component link 3 | | | +------------------+ | +------+ +---+--+ Figure 7: Concurrent path computation Consider the case where a TE link is composed of 3 ODU3 component links with 32TSs available on the first one, 24TSs on the second, 24TSs on the third and supporting ODU2 and ODU3 signal types. The node would advertise a TE link unreserved bandwidth equal to 80 TSs and a MAX LSP bandwidth equal to 32 TSs. In case of restoration the network could try to restore 2 ODU3 (64TSs) in such TE-link while only a single ODU3 can be set up and a crank-back would be originated. In more complex network scenarios the number of crank- backs can be much higher. 8. Maximum LSP Bandwidth Maximum LSP bandwidth is currently advertised in the common part of the ISCD and advertised per priority, while in OTN networks it is only required for ODUflex advertising. This leads to a significant Belotti, et al. Expires December 27, 2013 [Page 14] Internet-Draft GMPLS evaluation against G.709v3 OTN June 2013 waste of bits inside each LSA. 9. Distinction between terminating and switching capability The capability advertised by an interface needs further distinction in order to separate termination and switching capabilities. Due to internal constraints and/or limitations, the type of signal being advertised by an interface could be just switched (i.e. forwarded to switching matrix without multiplexing/demultiplexing actions), just terminated (demultiplexed) or both. The following figures help explaining the switching and terminating capabilities. MATRIX LINE INTERFACE +-----------------+ +-----------------+ | +-------+ | ODU2 | | ----->| ODU-2 |----|----------|--------\ | | +-------+ | | +----+ | | | | \__/ | | | | \/ | | +-------+ | ODU3 | | ODU3 | ----->| ODU-3 |----|----------|------\ | | | +-------+ | | \ | | | | | \| | | | | +----+ | | | | \__/ | | | | \/ | | | | ---------> OTU-3 +-----------------+ +-----------------+ Figure 8: Switching and Terminating capabilities The figure in the example shows a line interface able to: - Multiplex an ODU2 coming from the switching matrix into and ODU3 and map it into an OTU3 - Map an ODU3 coming from the switching matrix into an OTU3 In this case the interface bandwidth advertised is ODU2 with switching capability and ODU3 with both switching and terminating capabilities. This piece of information needs to be advertised together with the related unreserved bandwidth and signal type. As a consequence Belotti, et al. Expires December 27, 2013 [Page 15] Internet-Draft GMPLS evaluation against G.709v3 OTN June 2013 signaling must have the possibility to setup an LSP allowing the local selection of resources consistent with the limitations considered during the path computation. In figures 9 and 10 there are two examples of the need of termination/switching capability differentiation. In both examples all nodes only support single-stage capability. Figure 9 represents a scenario in which a failure on link B-C forces node A to calculate another ODU2 LSP path carrying ODU0 service along the nodes B-E-D. As node D is a single stage capable node, it is able to extract ODU0 service only from ODU2 interface. Node A has to know that from E to D exists an available OTU2 link from which node D can extract the ODU0 service. This information is required in order to avoid that the OTU3 link is considered in the path computation. ODU0 transparently transported +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | ODU2 LSP Carrying ODU0 service | | |'''''''''''''''''''''''''''''''''''''''''''| | | | | | | +----++ OTU2 +-----+ OTU2 +-----+ OTU2 ++----+ | ODU0 | | Link | | Link | | Link | | ODU0 ---->| A |_________| B |_________| C |_________| D |----> | | | | | | | | +-----+ +--+--+ +-----+ ++--+-+ | | | OTU3| | | Link| +-----+__________________| | | | | OTU3 Link | |____| E | | | |_____________________| +-----+ OTU2 Link Figure 9: Switching and Terminating capabilities - Example 1 Figure 7 addresses the scenario in which the restoration of the ODU2 LSP (ABCD) is required. The two bundled component links between B and E could be used, but the ODU2 over the OTU2 component link can only be terminated and not switched. This implies that it cannot be used to restore the ODU2 LSP (ABCD). However such ODU2 unreserved bandwidth must be advertised since it can be used for a different ODU2 LSP terminating on E, e.g. (FBE). Node A has to know that the ODU2 capability on the OTU2 link can only be terminated and that the restoration of (ABCD) can only be performed using the ODU2 bandwidth Belotti, et al. Expires December 27, 2013 [Page 16] Internet-Draft GMPLS evaluation against G.709v3 OTN June 2013 available on the OTU3 link. ODU0 transparently transported +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ | ODU2 LSP Carrying ODU0 service | | |'''''''''''''''''''''''''''''''''''''''''''| | | | | | | +----++ OTU2 +-----+ OTU2 +-----+ OTU2 ++----+ | ODU0 | | Link | | Link | | Link | | ODU0 ---->| A |_________| B |_________| C |_________| D |----> | | | | | | | | +-----+ ++-+-++ +-----+ +--+--+ | | | | OTU2| | | | +-----+ Link| | | OTU3 +-----+ | | | | | | Link | | | | F |_______| | |___________| E |___________| | | |_____________| | OTU2 Link +-----+ OTU2 Link +-----+ Figure 10: Switching and Terminating capabilities - Example 2 10. Priority Support The IETF foresees that up to eight priorities must be supported and that all of them have to be advertised independently on the number of priorities supported by the implementation. Considering that the advertisement of all the different supported signal types will originate large LSAs, it is advised to advertise only the information related to the really supported priorities. 11. Multi-stage multiplexing With reference to the [OTN-FWK], introduction of multi-stage multiplexing implies the advertisement of cascaded adaptation capabilities together with the matrix access constraints. The structure defined by IETF for the advertisement of adaptation capabilities is ISCD/IACD as in [RFC4202] and [RFC5339]. Modifications to ISCD/IACD, if needed, have to be addressed in the related encoding documents. With respect to the routing, please note that in case of multi stage Belotti, et al. Expires December 27, 2013 [Page 17] Internet-Draft GMPLS evaluation against G.709v3 OTN June 2013 multiplexing hierarchy (e.g. ODU1->ODU2->ODU3), not only the ODUk/ OTUk bandwidth (ODU3) and service layer bandwidth (ODU1) are needed, but also the intermediate one (ODU2). This is a typical case of spatial allocation problem. Suppose in this scenario to have the following advertisement: Hierarchy: ODU1->ODU2->ODU3 Number of ODU1==5 The number of ODU1 suggests that it is possible to have an ODU2 FA, but it depends on the spatial allocation of such ODU1s. It is possible that 2 links are bundled together and 3 ODU1->ODU2->ODU3 are available on a component link and 2 on the other one, in such a case no ODU2 FA could be set up. The advertisement of the ODU2 is needed because in case of ODU1 spatial allocation (3+2), the ODU2 available bandwidth would be 0 (no ODU2 FA can be created), while in case of ODU1 spatial allocation (4+1) the ODU2 available bandwidth would be 1 (1 ODU2 FA can be created). 12. Generalized Label The ODUk label format defined in [RFC4328] could be updated to support new signal types defined in [G.709-2012] but would hardly be further enhanced to support possible new signal types. Furthermore such label format may have scalability issues due to the high number of labels needed when signaling large LSPs. For example, when an ODU3 is mapped into an ODU4 with 1.25Gbps tributary slots, it would require the utilization of thirty-one labels (31*4*8=992 bits) to be allocated while an ODUflex into an ODU4 may need up to eighty labels (80*4*8=2560 bits). A new flexible and scalable ODUk label format needs to be defined. 13. Security Considerations This document provides an evaluation of OTN requirements against actual routing [RFC4202] and [RFC4203] and signaling mechanism [RFC3471], [RFC3473] and [RFC4328]in GMPLS. New types of information to be conveyed regard OTN containers and hierarchies and from a security standpoint this memo does not introduce further risks with respect to the information that can be Belotti, et al. Expires December 27, 2013 [Page 18] Internet-Draft GMPLS evaluation against G.709v3 OTN June 2013 currently conveyed via GMPLS protocols. For a general discussion on MPLS and GMPLS-related security issues, see the MPLS/GMPLS security framework [RFC5920]. 14. IANA Considerations This informational document does not make any requests for IANA action. 15. Contributors Jonathan Sadler, Tellabs EMail: jonathan.sadler@tellabs.com John Drake, Juniper EMail: jdrake@juniper.net Francesco Fondelli Ericsson Via Moruzzi 1 Pisa - 56100 Email: francesco.fondelli@ericsson.com 16. Acknowledgements The authors would like to thank Lou Berger, Eve Varma and Sergio Lanzone for their precious collaboration and review. 17. References Belotti, et al. Expires December 27, 2013 [Page 19] Internet-Draft GMPLS evaluation against G.709v3 OTN June 2013 17.1. Normative References [G.709-2012] ITU-T, "Rec G.709, version 4", approved by ITU-T in 2012. [G.798] ITU-T, "Revised version of G.798 Characteristics of optical transport network hierarchy equipment functional blocks", consented by ITU-T on December 2012. [G.872] ITU-T, "Revised version of G.872: Architecture of optical transport networks for consent", consented by ITU-T on December 2012. 17.2. Informative References [OTN-FWK] F.Zhang, D.Li, H.Li, S.Belotti, D.Ceccarelli, "Framework for GMPLS and PCE Control of G.709 Optical Transport Networks", work in progress draft-ietf-ccamp-gmpls-g709-framework-13, June 2013. [OTN-OSPF] D.Ceccarelli,D.Caviglia,F.Zhang,D.Li,Y.Xu,P.Grandi,S.Belot ti, "Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolutive G.709 OTN Networks", work in progress draft-ietf-ccamp-gmpls-ospf-g709v3-07, June 2013. [OTN-RSVP] F.Zhang, G.Zhang, S.Belotti, D.Ceccarelli, K.Pithewan, "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for the evolving G.709 Optical Transport Networks Control, work in progress draft-ietf-ccamp-gmpls-signaling-g709v3-10", November 2012. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. [RFC3471] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Functional Description", RFC 3471, January 2003. [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. Belotti, et al. Expires December 27, 2013 [Page 20] Internet-Draft GMPLS evaluation against G.709v3 OTN June 2013 [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. [RFC4328] Papadimitriou, D., "Generalized Multi-Protocol Label Switching (GMPLS) Signaling Extensions for G.709 Optical Transport Networks Control", RFC 4328, January 2006. [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. [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS Networks", RFC 5920, July 2010. Authors' Addresses Sergio Belotti (editor) 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 Daniele Ceccarelli (editor) Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy Email: daniele.ceccarelli@ericsson.com Belotti, et al. Expires December 27, 2013 [Page 21] Internet-Draft GMPLS evaluation against G.709v3 OTN June 2013 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 Belotti, et al. Expires December 27, 2013 [Page 22]