CCAMP Working Group D. Ceccarelli, Ed. Internet-Draft F. Fondelli Intended status: Informational Ericsson Expires: August 29, 2013 S. Belotti D. Papadimitriou, Ed. Alcatel-Lucent February 25, 2013 Multi layer implications in GMPLS controlled networks draft-bcg-ccamp-gmpls-ml-implications-04 Abstract This document describes requirements for MRN application to multiple hierarchies of technologies (e.g. OTN, SDH, ETH). For this purpose, after summarizing MRN definitions, rationales and currently supported applications, a problem statement is introduced together with its implications on GMPLS routing and signaling. New functional requirements are derived and MRN extensions required to address them are identified. 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 August 29, 2013. Copyright Notice Copyright (c) 2013 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 Ceccarelli, et al. Expires August 29, 2013 [Page 1] Internet-Draft Multi layer implications February 2013 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. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. MLN and MRN networks: relationship and rationale . . . . . . . 3 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 5 3.2. Signaling . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Applicability Scenarios . . . . . . . . . . . . . . . . . . . 8 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.1. Multiple internal matrices with different inter-link types . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2. Multiple internal matrices with different inter-link types and shared server layer capacity . . . . . . . . . . 12 5.3. Multistage multiplexing at different levels . . . . . . . 13 6. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 14 7. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Missing information . . . . . . . . . . . . . . . . . . . . . 20 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 21 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 12.1. Normative References . . . . . . . . . . . . . . . . . . . 21 12.2. Informative References . . . . . . . . . . . . . . . . . . 22 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Ceccarelli, et al. Expires August 29, 2013 [Page 2] Internet-Draft Multi layer implications February 2013 1. Introduction Generalized MPLS (GMPLS) supports the control of multiple switching technologies: packet switching, Layer-2 switching, TDM (Time-Division Multiplexing) switching, wavelength switching, and fiber switching ([RFC3945]). The Interface Switching Capability concept has been defined for the advertisement of the Switching Capabilities of the different interfaces of a node [RFC4202], while in the context of Multi Region Networks (MRN) the Interface Adjustment Capabiltiy concept has been introduced [RFC5339] for the advertisement of adjustment capacity within an hybrid node. With the introduction of G709v3 networks, a new Switching Capability (OTN-TDM) has been defined [OSPF-OTN] and the ISCD updated in order to cope with the OTN specific multi stage multiplexing capabilities. The new Switching Capability Specific Information (SCSI) field provides information about the bandwidth availability at each layer of the OTN hierarchy and about the operations that can be performed on the different layers, in terms of termination and switching capabilities. These issues have been addressed in the OTN documents within the OTN multi layer scope but need to be extended to MRNs, where the termination of a hierarchical LSP leads to the need of properly managing different switching capabilities and different adaptation functions. The scope of this document is to describe requirements when MRN is applied to multiple hierarchies of technologies (OTN, SDH, ETH). For this purpose, after summarizing MRN definitions, rationales and currently supported applications, a problem statement is introduced together with its implications on GMPLS routing and signaling. We derive new functional requirements and determine the corresponding MRN extensions that may be required to address them. 1.1. Terminology 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. MLN and MRN networks: relationship and rationale As per [RFC5212], the definition of MLNs and MRNs is as follows: Ceccarelli, et al. Expires August 29, 2013 [Page 3] Internet-Draft Multi layer implications February 2013 - MLN: "a Traffic Engineering (TE) domain comprising multiple data plane switching layers either of the same ISC (e.g., TDM) or different ISC (e.g., TDM and PSC) and controlled by a single GMPLS control plane instance" - MRN: "is defined as a TE domain supporting at least two different switching types (e.g., PSC and TDM), either hosted on the same device or on different ones, and under the control of a single GMPLS control plane instance" A network which is an MLN but not an MRN (i.e. multiple layers but a single switching capability), like for example an OTN domain, can be advertised via the utilization of the Interface Switching Capability Descriptor (ISCD). The ISCD is defined in [RFC4202] and its technology specific extensions (SCSI) are defined in different memos depending on the technology, e.g. the OTN ones in [OSPF-OTN] and the SDH ones in [RFC4203]. On the other side MRNs (i.e. multiple layers with multiple switching capabilities), like for example an OTN data plane (with one or more layers) over a WDM data plane (with one or more layers) controlled by a single GMPLS instance, need the utilization of an ISCD for each technology and an Interface Adjustment Capability Descriptor (IACD) [RFC6001] for the advertisement of the internal links providing adjustment between the switching capabilities. A node able to terminate data links (over the same interface) with different switching capabilities is called hybrid node. [RFC5212]. For more details please see Section 7. Hybrid nodes have been introduced not only to address the case of nodes able to switch/terminate LSPs from different switching capability but also to perform for instance: - Traffic-grooming: base GMPLS doesn't enable insertion of traffic at an intermediate point along an established LSP, i.e., the control plane limits the flexibility of nesting LSP only at the head-end of the underlying LSP. MRN extensions enable to multiplex and demultiplex e.g. PSC LSP into LSC LSP even if the LSC LSP does not originate or end at the nodes where the PSC LSP are multiplexed or demultiplexed. - Transparent regeneration: enables certain nodes equipped with PSC + LSC capability to regenerate the photonic signal without interrupting the LSC LSP. This functionality enables to setup end-to-end LSC even if certain intermediate nodes are being used to regenerate the signal at the PSC level. This means that MRN extends the node functionality beyond "terminate Ceccarelli, et al. Expires August 29, 2013 [Page 4] Internet-Draft Multi layer implications February 2013 or switch". The central notion in MRN is "adjustment capability". Adjustment capability assumes the availability of adjustment capacity or adjustment pool at given SC (say SC Z, in the following). An adjustment capability is the mean by mean which LSPs can be adapted/ mapped from one SC X to SC Y via Z, translated from one SC X to SC Y via Z or inserted (e.g., multiplexed or demultiplexed) from SC X to SC Y via Z. Note that SC X value MAY be identical to SC Y value and that SC Z value MAY be identical to SC X or Y value. For instance, when referring to transparent regeneration SC X = LSC = SC Y and SC Z = PSC and when referring to traffic grooming SC X = PSC and SC Y = LSC and SC Z = resource pool enabling the insertion of packet LSP into a lambda LSP. Advertisement of adjustment capacity by a given node assumes the functionality of adjustment is locally supported. 3. Problem Statement The MRN architectural framework as specified in [RFC6001] models the internal properties of the nodes by its internal switching capabilities (referred to as resource pools) and their interconnection, i.e. single and multiple pool models. However, it assumed that i) the internals properties of (logical) resource pools were left uncovered to external nodes, i.e., the technology specific details composing pools were not part of the IACD advertisement, and ii) the topology defined by the interconnection of resource pools is not defining any cycle, i.e., resource pools were not meshed (following the SC value hierarchy). The below describes in more details the underlying consequences for what concerns "routing" and "signaling". Note that beside listing the SC that have an internal multiplexing / encapsulation tructure we omit technology specific details to keep the problem description as generic as possible and thus applicable to Ethernet (C-VID, S-VID, I-SID, B-VID), SDH, OTN, and future technologies. 3.1. Routing When referring to routing, two specific elements are to be considered: representation (information) and exchange. The latter is not different from any other information exchange detailed in GMPLS RFCs; hence, not further discussed in the context of this document. The former raises however the following point: how to represent the relations between resource pools and their capabilities (beyond un/ Ceccarelli, et al. Expires August 29, 2013 [Page 5] Internet-Draft Multi layer implications February 2013 used capacity). The example of Fig.1 is illustrative. A,B,C,D and E represent the external interfaces of the node, while W,X,Y and Z the internal switching capacities. If the internal switching capabilities are associated to the same SC (SC W = SC X = SC Y = SC Z), they could either be represented as a single (logical) resource pool or be kept separated into different resource pools at the condition that their ingress and egress relations does not lead to any loop, i.e., there is no "X-Y" direct relationship. ***A*******B*C*D*** * | | | | * * | | | W * * | | | | * * | / \|/ * * | XxxxY * * | | / | * * ---- Z | * * \ / * * | * ***********E******* Figure 1: Problem statement - Routing Moreover, assuming that X and Y are part of the same logical resource pool (SC X = SC Y) but different from the two others, the properties of the two relationships between the resource pool (associated to SC Z) and the upper one (SC X = SC Y) may be not identical. In particular, the encoding associated to each relationship can be different (while there is only one encoding field per IACD sub-TLV), for example we could have an L2SC (for SC Z) with two different encapsulation method GFP-F or GFP-T towards common resource pool TDM (= SC X = SC Y). 3.2. Signaling Initially GMPLS signaling relies on link property inference for label allocation. This technique has been progressively complemeted by technology specific information encoded as part of the label request. In the present case, multiplexing hierarchies are interconnected but there is no (TE) link describing these interconnections. Hence, a mechanism is to be found by which the relationships between them have to be locally accommodated at provisioning time. Ceccarelli, et al. Expires August 29, 2013 [Page 6] Internet-Draft Multi layer implications February 2013 ***A*******B*C*D*** * | | | | * * | | | W * * | | | | * * | / \|/ * * | X Y * * | | / | * * ---- Z | * * \ / * * | * ***********E******* Figure 2: Problem statement - Signaling The case depicted in the above Figure 2 provides a simple illustration. Let's assume that X, Y, and Z are internal switching capabilities each defining a multiplexing structure. Let's further consider that X and Z are part of the same logical resource pool (SC X = SC Z). Hence, an external node receives the routing information from which it can derive as depicted in Fig.3 the relations between i) resource pools O, W, Y and ii) resource pools O, W, Y and "external" interfaces A, B, C, D, E. ***A*******B*C*D*** * | | | | * * | | | W * * | | | | * * | / \|/ * * -----O - Y * * \ / * * | * ***********E******* Figure 3: Problem statement - Relationship between resource pools There are four ways to reach interface (I/F) B from I/F E: E->O->Y->B, E->Y->O->B, E->O->B, E->Y->B. Hence, each time there is possible choice to pass from one SC to another SC (which is not associated to an "external" interface), there should be a mean by which the requester can indicate which SC it would like to make use of or equivalently exclude. In the present case, needs to have the mean by which it can select if the incoming/outgoing signal will go through O or Y. MRN signaling (see Section 4.1 of RFC 6001) enables such choice but only if SC O =/= SC Y. Ceccarelli, et al. Expires August 29, 2013 [Page 7] Internet-Draft Multi layer implications February 2013 In other terms, MRN signaling provides the mean to prevent selection/ exclude certain SC (see Section 4.1 of RFC 6001) along signaled path, but it doesn't allow to select among two resource pools associated to the same SC. 4. Applicability Scenarios When moving from OTN MLNs to general MRNs, the multiplexing tree concept introduced in [OSPF-OTN] needs to be extended so to take into account both different switching capabilities within the same muxing tree and adaptations between client hierarchies and server hierarchies. In the following figure an example of muxing tree supporting TDM, PSC, OTN-TDM and LSC hierarchies mixed together is shown. VC-4 | ODU1 STM-16 PSC L2SC | | | | | | | | ODU2 ODU2 ODU1 | \ \ / / \ \ / / \ \ / / \ \ / / \ \/ / \_ _ODU3__/ | OCh Figure 4: Muxing tree As it is possible to understand from the figure above, an MRN equipment can host a variety of client-server relationships. Four different scenarios can be identified: - A signal type X is a client to a Signal type Y (1:1) - e.g. Ethernet over WDM - A signal type X is a client to a Intra switching technology Hierarchy Y (1:N) - e.g. Ethernet over OTN - An Intra switching technology Hierarchy X is a client to a Signal Type Y (M:1) - e.g. ODU over WDM Ceccarelli, et al. Expires August 29, 2013 [Page 8] Internet-Draft Multi layer implications February 2013 - An Intra switching technology Hierarchy X is a client to an Intra switching technology Hierarchy Y (M:N) - e.g. SDH over OTN Being the first three scenarios a particular case of the fourth one, in the following only the general case of M:N relationship will be addressed. This kind of client-server hierarchy can be achieved, depending on the impelemntation, via single board or a cascade of them. In the latter case boards are connected via internal links, which can be either intra or inter switching capaility (e.g. ODU2->ODU3 or PSC->LSC). Those links should not be modeled as external TE links, but there is the need to advertise their characteristics and availability in terms of bandwidth and optical parameters. +--------------------------------------------------------+ | +------------+ Eth +------------+ | | | | | | | | | OTU-1 +----+ | | +----+ | | | +----+ | | +--> + | | | | | 8 | | | 4 | | | | OTU-1 |ODU1+------+| |ODU2+------+| OTU-3 | | +----+ |ODU-2 |..........>+ |ODU-3 |+----------|--> | | +------+|Internal | +------+| | | OTU-1| | |Physical | | | | | +----+ | | Link + | | | | +----+ | (OTU-2) +----+ | | | | | | | | | +------------+ +------------+ | +--------------------------------------------------------+ Figure 5: Cascaded muxponder Moreover, as described in [RFC5212], in a hybrid node there is the need to take into account also the node's internal adjustment capabilities between the switching technologies supported. An example of hybrid node with different switching matrices is shown in the following figure, where both an SDH and OTN matrix are available and the two switching elements are internally interconnected so that it is possible to terminate some resources (e.g. OTN interface Y1) or provide adjustment for the SDH traffic (e.g. OTN interface Y2 toward the SDH matrix). In addition to the internal links between matrices it is possible to have internal links between matrices and cascaded cards for the creation of the muxing hierarchy. In the example below both the SDH and OTN matrices are client to an Ceccarelli, et al. Expires August 29, 2013 [Page 9] Internet-Draft Multi layer implications February 2013 ODU2->ODU3 muxponder (through interfaces Y4 and Y5), which in turn is client to an OCh WSS. | 10GbE +-------------------------+-------------+ | | | | | | +-+ | +---------+ | | |X| | X1 | | | | __+-+__|__________| \ / | | | | ` \/ | X3 | | | X2 | /\ '''| | ODU2 | | |''''' / \ | | | Y6+---+ | +---------+ | | | +---+ | | +---+ | | | | | | | |SDH| + | Y5 | | ODU3| | | | | |__+---+__| +-----+ +----+| | | | | | | || OTU3/OCH| +---+ | | | | | ++----------+ |WSS| +--- | | Y4 | | || Y7 | +---+ |Y8 | | +----------+ ...... +----+| | | +-+ | | | \ / | | ___| |+--+ | | | |Y| | |Y2 | \/ | | | +---+|OT| | | | +-+ | .....| /\ |Y3| | +--+ | +---------+ -------+----------+ / \ | | | | | Y1 | .... | | | | +---+ | | + | | | |OTN| | | ODU2 | | |__+---+___| | +---------------------------------------+ Figure 6: Hybrid node with optical muxponder and different switching matrices 5. Use Cases 5.1. Multiple internal matrices with different inter-link types Ceccarelli, et al. Expires August 29, 2013 [Page 10] Internet-Draft Multi layer implications February 2013 PT21 +-----------+ `-.._ OTU2 +------------+ '''' TDM | | `-+.._+ NRZ,RS-FEC | | | Switch#1 +----+ +---+ | _:----------------| | '''' | | | |.+-' | | +-----------+ |.-' | | | | PT20 `-.._ OTU3,coherent, | | | | `-+.._+ HD-FEC | | .' ---+ | _-----------------| LSC | +-----------+ .' | | |.+-' | Switch | '''| TDM .' |.-' | | | Switch#2 `. `-.._ OTU3 ,coherent_| |OTS line '''| | `. | | `-+.._+ SD-FEC | +-------- +-----------+ `. +---+ | _:----------------| | | | |.+-' | | OTU,Eth, PT21|.-' | | FC, SDH, Sonet | | lines as input `-.._ OTU4, coherent,| | PT21| | `-+.._+ HD-FEC | | .' +---+ | _:----------------| | +-----------+ .' | | |.+-' | | '''| TDM |' |.-' | | | Switch#3 | UTU2 , NRZ | | '''| | `. | | |-+.._+ RS-FEC | | +-----------+ `. +---+ | _:----------------| | PT21| | |.+-' | | |.-' +------------+ Figure 7: Multiple internal matrices with different inter-link types A single IACD sub-TLV is associated to describe all the 1:1 relationships TDM_i (i = 1,2,3) - LSC. When TDM-LSC has multiple relations, the following alternatives are possible: - the IACD sub-TLV aggregates information (assuming multiple LSP encodings could be listed in a single IACD sub-TLV) - a dedicated IACD sub-TLV describes each 1:1 relation TDM_ij - LSC (i=1,2,3; j=1,2) Note: one ISCD sub-TLV is associated to each TDM_i interface (left part of the figure) or a single ISCD sub-TLV (bundle) can describe all TDM interfaces Ceccarelli, et al. Expires August 29, 2013 [Page 11] Internet-Draft Multi layer implications February 2013 5.2. Multiple internal matrices with different inter-link types and shared server layer capacity PT21 +-----------+ `-.._ OTU2 +------------+ '''' OTN | | `-+.._+ NRZ,RS-FEC | | | Switch#1 \----+ +---+ | _:----------------| | '''' |\ | | |.+-' | | +-----------\ \ |.-' | | | \ PT20 | | \ \`-.._ OTU3,coherent, | | \ + | `-+.._+ HD-FEC | | |.' ---+ | _-----------------| LSC | +-----------+ .\ | | |.+-' | Switch | '''| SDH .' \|.-' | | | Switch#2 `. |-..PT21 OTU3 ,coherent_| |OTS line '''| | `. + | `-+.._+ SD-FEC | +-------- +-----------+ +-- +---+ | _:----------------| | | | .' |.+-' | | OTU,Eth, | .-' | | FC, SDH, Sonet +-++ | | lines as inp / \ +| | +---+--+GFP-F | | | | | +-----------+ | + | | '''| Ethernet '''| | | | Switch#3 | `. OTU4,coherent | | '''| | | `-. `-+.._+ HD-FEC | | +----------- `.. . +---+ | _:----------------| | | +-+ | |.+-' | | GFP-T | | |.-' +------------+ |-' PT21 Figure 8: Multiple internal matrices with different inter-link types and shared server layer capacity + Like in the previous example, a single IACD sub-TLV is associated that describes each 1:1 relation (i.e., OTN_i-LSC, ETH_i -LSC) (note that in this figure i=1). The 1:N relation between the LSC switch and the SDH - OTN - ETH switches is decomposed as follows: Ceccarelli, et al. Expires August 29, 2013 [Page 12] Internet-Draft Multi layer implications February 2013 - A single IACD sub-TLV describes the 1:1 relation between the LSC switch and the PTx - A single IACD sub-TLV describes the 1:1 relation between the PTx and the ETH, SDH, or OTN switch (one single IACD sub-TLV independently from the number of legs between the switches and PTx) If the hub-and-spoke/star relationships is limited and the PTx capability "static", then each OTN-LSC, SDH-LSC, ETH-LSC 1:1 relationship can be described by a dedicated IACD sub-TLV (like in Fig.1). Note_2: one ISCD sub-TLV is associated to each ETH, SDH, OTN interfaces (left part of the figure) 5.3. Multistage multiplexing at different levels Ceccarelli, et al. Expires August 29, 2013 [Page 13] Internet-Draft Multi layer implications February 2013 +------------+ | | | | | | | | PT20 | | | `-.._ OTU3,coherent, | | | OTN/FC/SDH/ETH + | `-+.._+ HD-FEC | | | client ' ---+ | _-----------------| LSC | +--------------------+ | |.+-' | Switch | +--. |.-' | | | | `-. `-+.._ |-..PT21 OTU3 ,coherent_| |OTS line +-- +---+ | _-----+ | `-+.._+ SD-FEC | +-------- +-+ | |.+-' - +---+ | _:----------------| | | |.-' | .' |.+-' | | ' PT21 .-' | | ETH client | | +| | FC client | | +------------ | | | |. PT21 + | | +-+ `-. `-+.._ | | . | +---+ | _:-----. OTU4,coherent | | +-+ | |.+-' | `-. `-+.._+ HD-FEC | | | |.-' . . +---+ | _:----------------| | ' +-+ | |.+-' | | OTN client | |.-' +------------+ ETH ' PT21 + Figure 9: Multistage multiplexing at different levels A single IACD sub-TLV is associated that describes each 1:1 relation between the ISCD sub-TLV associated to each interface and the LSC switch. In case, the PTx tree structure and associated un/used capacity varies over time the MAX LSP Bandwidth value(s) is/are to be tuned accordingly. Advertising the PTx tree structure (which actually instantiates each 1:1 relation) requires structuring the "Adjustment Capability-specific information" of the corresponding IACD sub-TLV. 6. Requirements In order to deal with all the scenarios depiscted in the previous sections, protocol extensions need to take into account the following Ceccarelli, et al. Expires August 29, 2013 [Page 14] Internet-Draft Multi layer implications February 2013 set of requirements. 1. It must be possible to identify from which branch of X to which branch of Y the mapping is performed. Due to a restricted connectivity to a given switching layer, not all the indicated branches are really available. An example of such limitations can be seen in figure Figure 6, where for example the SDH client can be mapped only on itnerface Y5 of the muxponder board or the 10GbEth on interface Y6. In figure Figure 4 it is also possible to see that the OTN has a hierarchy with 3 branches (i.e. ODU1->ODU2->ODU3, ODU2->ODU3 and ODU1->ODU3) and an SDH signal can be mapped only over the ODU2->ODU3 branch while an Ethernet one can be mapped only on the ODU1->ODU3). So it is not eough to say that SDH can be mapped over ODU or Eth over ODU as further info is needed. Moreover it is also not enough to say that Eth is mapped over ODU1 because in the same example 2 different branches have the ODU1 as the top most layer (i.e. ODU1->ODU2->ODU3 and ODU1->ODU3) and not both of them can support Eth mapping. 2. Adaptation information from X to Y to be used both in case of Y being switched and X mapped over it or in case of both X and Y being switched. Please note that more than one type of adaptation might be availble. 3. Amount of available bandwidth in the mapping between X and Y (as per actual IACD definition) 4. It must be possible to advertise intra-switching capability associated to internal links. A typical case is a hierarchy gained through the cascade of multiple cards (e.g. trasnponders, muxponders) and the link from one board to the other one has a given bandwidth. 5. It must be possible to advertise inter-switching capability associated to internal links. A typical case is a M:N client- layer hierarchy gained through the cascade of multiple cards (e.g. SDH client to a muxponder card) and the link from one board to the other one has a given bandwidth. 7. Evaluation [RFC6001] defined the Interface Adjustment Capability Descriptor (IACD) for the advertisement of internal adjustment capability of hybrid nodes [RFC5212]. A common adjustment pool is a pool of reservable and sharable resources that are i) allocated on demand/dynamically and ii) either Ceccarelli, et al. Expires August 29, 2013 [Page 15] Internet-Draft Multi layer implications February 2013 assigned to a single SC (single adjustment pool model) or multiple SC (multiple adjustment pool model) or possibly their combination. In the former case (single pool model), the "lower SC" value of the IACD sub-TLV (associated to the adjustment pool) is set to the SC value of ISCD sub-TLV of the interface that interfaces with the adjustment pool. The "upper" SC value of the IACD (associated to the adjustment pool) determines the SC capability of the resource pool itself. In this case the (upper) encoding is set to 0xFF. In other terms, the capacity of the adjustment pool is not directly accessible - over the wire - by other nodes belonging to the same TE domain (assuming homogeneous LSP encoding type along the LSP path). This model (see Example 1) is typically used when the node matrix switching capability is not terminating/initiating any LSP (the node only exposes the capability associated to its I/O) but nodes part of the same TE domain can still take into account the adjustment capacity usage on that node. In the latter case (multiple pool model), the "lower SC" value of the IACD sub-TLV (associated to the adjustment pool) is set to the SC value of ISCD sub-TLV of the interface(s) that interfaces with the adjustment pool. The "upper" SC value of the IACD sub-TLV (associated to the adjustment pool) determines the SC capability of the adjustment pool itself. However, the (upper) SC value of the IACD sub-TLV shall correspond to at least one of the SC values associated to one of the ISCD sub-TLVs, i.e., the adjustment pool SC value shall be covered by at least one of the SC values associated to the ISCD sub-TLVs. In other terms, the capacity of the adjustment pool is directly accessible compared to the single pool model. This model (see Example 2) is typically used when nodes expose their full (multi-level) grooming and initiation/ termination capacity. Example of single pool model: in the IACD sub-TLV the "upper" SC type = TDM/HO-SDH, and the "lower" SC type being respectively "L2SC" and "OTH/TDM". In this example, the capacity associated to the IACD represents the "interconnection capacity" between the interface X (L2SC or OTH) to Y = (HO-SDH/TDM). The encoding type associated to the upper SC is set to 0xFF. Ceccarelli, et al. Expires August 29, 2013 [Page 16] Internet-Draft Multi layer implications February 2013 ^ ^ ^ | | | +-------------------------------------+ | Network | | ... | | | element | | | | | +---------+ | | +------| L2SC |<----+ | | | | | | | | | +---------+ | | | | | | | | +---------+ | | | +----->| HO-SDH |-----+ | | +------| |<----+ | | | +---------+ | | | | | | | | +---------+ | | | +----->| |-----+ | | _ | | _ | | / | | | | \ | Fiber 1 | / |-----| OTH |-----| \ | Fiber 1 -----|---| |-----| |-----| |---|---- ... | | |-----| |-----| |...| -----|---| |-----| |-----| |---|---- Fiber N | \ |-----| |-----| / | Fiber N | \_| +---------+ |_/ | +-------------------------------------+ Figure 10: Example of single pool model The advertisement for the node interfaces will be: + L2SC interfaces - ISCD sub_TLV 1 for L2SC interface - IACD sub_TLV 1 for L2SC to HO-SDH (1) in figure above + OTH inferfaces - ISCD sub_TLV 1 for OTH interface - IACD sub_TLV 1 for OTH to HO-SDH (2) in figure above Example of multiple pool model: In this case we will show two examples, the first of which does not foresee any interconnection between the L2SC and the HO-SDH matrices, while the second one does. Ceccarelli, et al. Expires August 29, 2013 [Page 17] Internet-Draft Multi layer implications February 2013 In the former case there is at least one ISCD sub-TLV of SC = X corresponding to the lower SC value (HO-SDH/TDM) of the IACD sub-TLV associated to the first adjustment pool (HO-SDH/TDM), and one ISCD sub-TLV of type SC = Y corresponding to the lower SC value (L2SC) of the IACD sub-TLV associated to the second adjustment pool Y (L2SC). In this example, the capacity associated to the IACD represents the "interconnection capacity" between the pool of SC = X (HO-SDH/TDM) to Y (L2SC). Each TE Link 1...N is able to get access to this adjustment capacity. +------------------------------------------------+ | Network | | element | | +---------+ | | +---------| L2SC |<---------+ | | | **| |** | | | | * +---------+ * | | | | * * | | | | * +---------+ * | | | | **| |** | | | | +-------| HO-SDH |<-------+ | | | | | | | | | | | | | +---------+ | | | | | | | | | | | | +---------+ | | | | | | | | | | | | _ | | | | | | _ | | / |<- | | | | +| \ | Fiber 1 | / |<--+ | OTH | +--| \ | Fiber 1 -----|--| |-----------| |-----------| |---|---- ... | | |-----------| |-----------| |...| -----|--| |-----------| |-----------| |---|---- Fiber N | \ |-----------| |-----------| / | Fiber N | \_| +---------+ |_/ | +------------------------------------------------+ Figure 11: Example of multiple pool model - No interconnection between OTH and HO-SDH In this case the advertisement, which is the same for each of the N TE Link is: - ISCD sub_TLV for LSC - ISCD sub_TLV for HO-SDH Ceccarelli, et al. Expires August 29, 2013 [Page 18] Internet-Draft Multi layer implications February 2013 - ISCD sub_TLV for OTH - IACD sub_TLV for LSC to HO-SDH (starred link) On the other side, if we consider the same scenario including the inteconnection between the OTH and HO-SDH matrices, as shown in figure below, the advertisement changes as follows. +------------------------------------------------+ | Network | | element | | +---------+ | | +---------| L2SC |<---------+ | | | **| |** | | | | * +---------+ * | | | | * * | | | | * +---------+ * | | | | **| |** | | | | +-------| HO-SDH |<-------+ | | | | | ..| |.. | | | | | | : +---------+ . | | | | | | : : | | | | | | : +---------+ : | | | | | | : | | : | | | | _ | | :.| |.: | | _ | | / |<- | | | | +| \ | Fiber 1 | / |<--+ | OTH | +--| \ | Fiber 1 -----|--| |-----------| |-----------| |---|---- ... | | |-----------| |-----------| |...| -----|--| |-----------| |-----------| |---|---- Fiber N | \ |-----------| |-----------| / | Fiber N | \_| +---------+ |_/ | +------------------------------------------------+ Figure 12: Example of multiple pool model - With interconnection between OTH and HO-SDH This time the advertisement is modified as follows: - ISCD sub_TLV 1 for LSC - ISCD sub_TLV 2 for HO-SDH - ISCD sub_TLV 3 for OTH Ceccarelli, et al. Expires August 29, 2013 [Page 19] Internet-Draft Multi layer implications February 2013 - IACD sub_TLV 1 for LSC to HO-SDH (starred link) - IACD sub_TLV 2 for HO-SDH to OTH (dotted link) The IACD is the only object defined in routing for the management of hybrid nodes. It provides the information for the forwarding/ switching capability and is used in addition to the ISCD. 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Lower SC | Lower Encoding| Upper SC | Upper Encoding| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Adjustment Capability-specific information | | (variable) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: IACD format 8. Missing information The pieces of information needed for addressing the requirements listed in Section 6 are: - Mapping information from a client to a server layer. E.g. an ethernet client could be mapped over and OTN hierarchy using a GFP-F or GFP-T adaptation. Ceccarelli, et al. Expires August 29, 2013 [Page 20] Internet-Draft Multi layer implications February 2013 - Connectivity constraints: need to describe optical transponder muxing scheme with positioning and restricted connectivity in order to provide end to end connectivity. In the example shown in picture Figure 4, the capability of muxing an SDH hierarchy is shown, but the SDH cannot be injected in any branch of the OTN hierarchy. There is the need to specify that the SDH hierarchy can be only muxed into the ODU->ODU3 branch of the OTN hierarchy and not in all of them. - Multistage interswitching capability: The IACD already allows advertising the multiplexing of single and multi-stage muxing scenarios like the one in the reference muxing tree, where an SDH hierarchy is muxed over an OTN hierarchy, which is againg muxed over an OCh (two levels of muxing). 9. IANA Considerations TBD 10. Contributors TBD 11. Acknowledgements TBD 12. References 12.1. Normative References [OSPF-OTN] D.Ceccarelli, D.Caviglia, F.Zhang, D.Li, S.Belotti, P.Grandi, R.Rao, K.Pithewan, J.Drake, "Traffic Engineering Extensions to OSPF for Generalized MPLS (GMPLS) Control of Evolving G.709 OTN Networks, work in progress draft-ietf-ccamp-gmpls-ospf-g709v3-03", August 2012. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005. Ceccarelli, et al. Expires August 29, 2013 [Page 21] Internet-Draft Multi layer implications February 2013 [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005. [RFC5212] Shiomoto, K., Papadimitriou, D., Le Roux, JL., Vigoureux, M., and D. Brungard, "Requirements for GMPLS-Based Multi- Region and Multi-Layer Networks (MRN/MLN)", RFC 5212, July 2008. [RFC6001] Papadimitriou, D., Vigoureux, M., Shiomoto, K., Brungard, D., and JL. Le Roux, "Generalized MPLS (GMPLS) Protocol Extensions for Multi-Layer and Multi-Region Networks (MLN/ MRN)", RFC 6001, October 2010. 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. Authors' Addresses Daniele Ceccarelli (editor) Ericsson Via Melen 77 Genova - Sestri Ponente Italy Email: daniele.ceccarelli@ericsson.com Francesco Fondelli Ericsson Via Moruzzi 1 Pisa Italy Email: francesco.fondelli@ericsson.com Ceccarelli, et al. Expires August 29, 2013 [Page 22] Internet-Draft Multi layer implications February 2013 Sergio Belotti Alcatel-Lucent Via Trento, 30 Vimercate Italy Email: sergio.belotti@alcatel-lucent.com Dimitri Papadimitriou (editor) Alcatel-Lucent Copernicuslaan 50 Antwerpen B-2018 Belgium Email: dimitri.papadimitriou@alcatel-lucent.be Ceccarelli, et al. Expires August 29, 2013 [Page 23]