CCAMP Working Group D. Ceccarelli Internet-Draft Ericsson Intended status: Informational S. Belotti Expires: January 8, 2013 D. Papadimitriou Alcatel-Lucent July 7, 2012 Multi layer implications in GMPLS controlled networks draft-bcg-ccamp-gmpls-ml-implications-00 Abstract This document defines requirements and uses cases for the extension of the OTN MLN work to MRNs. It also provides an evaluation of already existing solutions againts new requirements. 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 January 8, 2013. Copyright Notice Copyright (c) 2012 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 Ceccarelli, et al. Expires January 8, 2013 [Page 1] Internet-Draft Multi layer implications July 2012 described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Applicability Scenarios . . . . . . . . . . . . . . . . . . . 3 3. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 4. Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 9 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 8.1. Normative References . . . . . . . . . . . . . . . . . . . 9 8.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 Ceccarelli, et al. Expires January 8, 2013 [Page 2] Internet-Draft Multi layer implications July 2012 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. Scope of this document is describing new requirements derived from the extension of OTN MLN hierarchies to MRNs and evaluating impacts on existing solutions. 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. 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 mapping adaptations between client hierarchies and server hierarchies. Ceccarelli, et al. Expires January 8, 2013 [Page 3] Internet-Draft Multi layer implications July 2012 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 1: 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 - 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 Ceccarelli, et al. Expires January 8, 2013 [Page 4] Internet-Draft Multi layer implications July 2012 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 2: 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 ODU2->ODU3 muxponder (through interfaces Y4 and Y5), which in turn is client to an OCh WSS. Ceccarelli, et al. Expires January 8, 2013 [Page 5] Internet-Draft Multi layer implications July 2012 | 10GbE +-------------------------+-------------+ | | | | | | +-+ | +---------+ | | |X| | X1 | | | | __+-+__|__________| \ / | | | | ` \/ | X3 | | | X2 | /\ '''| | ODU2 | | |''''' / \ | | | Y6+---+ | +---------+ | | | +---+ | | +---+ | | | | | | | |SDH| + | Y5 | | ODU3| | | | | |__+---+__| +-----+ +----+| | | | | | | || OTU3/OCH| +---+ | | | | | ++----------+ |WSS| +--- | | Y4 | | || Y7 | +---+ |Y8 | | +----------+ ...... +----+| | | +-+ | | | \ / | | ___| |+--+ | | | |Y| | |Y2 | \/ | | | +---+|OT| | | | +-+ | .....| /\ |Y3| | +--+ | +---------+ -------+----------+ / \ | | | | | Y1 | .... | | | | +---+ | | + | | | |OTN| | | ODU2 | | |__+---+___| | +---------------------------------------+ Figure 3: Hybrid node with optical muxponder and different switching matrices 3. Requirements In order to deal with all the scenarios depiscted in the previous sections, protocol extensions need to take into account the following 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 3, 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 1 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 Ceccarelli, et al. Expires January 8, 2013 [Page 6] Internet-Draft Multi layer implications July 2012 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. 4. Evaluation [RFC6001] defined the Interface Adjustment Capability Descriptor (IACD) for the advertisement of internal adjustment capability of hybrid nodes [RFC5212]. This 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. Ceccarelli, et al. Expires January 8, 2013 [Page 7] Internet-Draft Multi layer implications July 2012 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 4: IACD format The information needed for addressing the requirements listed in Section 3 are: - Mapping from a client to a server layer - 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 1, 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 only allows the multiplexing of a hierarchy of a given switching capability into a hierarchy of a different swithcing capability (aka single stage muxing in OTN documents), but it must be possible to advertise also multi-stage muxing scenarios like the one in the reference muxing tree, where an SDH hierarchy is muxed over an OTN Ceccarelli, et al. Expires January 8, 2013 [Page 8] Internet-Draft Multi layer implications July 2012 hierarchy, which is againg muxed over an OCh (two levels of muxing). [EDITOR NOTE: following notes to be considered] We also defined two more cases depending on the node capabilities with respect to the client hierarchy X. A. Both Signal type/Hierarchy X and Y can be switched by the NE, i.e. it has a matrix able to switch X and a matrix able to switch Y but the interface is only Y capable. The advertisement will include the following pieces of information - ISCD referring to Y - IACD - Adaptation information for X--Y B. Only Signal type/Hierarchy Y can be switched by the NE while X is only mapped into Y: The advertisement will include the following pieces of information - ISCD referring to Y - Adaptation information for X--Y 5. IANA Considerations 6. Contributors 7. Acknowledgements 8. References 8.1. Normative 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-05", September 2011. [OTN-INFO] S.Belotti, P.Grandi, D.Ceccarelli, D.Caviglia, F.Zhang, D.Li, "Information model for G.709 Optical Transport Networks (OTN), work in progress draft-ietf-ccamp-otn-g709-info-model-02", October 2011. [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. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998. Ceccarelli, et al. Expires January 8, 2013 [Page 9] Internet-Draft Multi layer implications July 2012 [RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998. [RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003. [RFC4201] Kompella, K., Rekhter, Y., and L. Berger, "Link Bundling in MPLS Traffic Engineering (TE)", RFC 4201, October 2005. [RFC4202] Kompella, K. and Y. Rekhter, "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, October 2005. [RFC4203] Kompella, K. and Y. Rekhter, "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, October 2005. [RFC5250] Berger, L., Bryskin, I., Zinin, A., and R. Coltun, "The OSPF Opaque LSA Option", RFC 5250, July 2008. [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, 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. 8.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. Ceccarelli, et al. Expires January 8, 2013 [Page 10] Internet-Draft Multi layer implications July 2012 Authors' Addresses Daniele Ceccarelli Ericsson Via A. Negrone 1/A Genova - Sestri Ponente Italy Email: daniele.ceccarelli@ericsson.com Sergio Belotti Alcatel-Lucent Via Trento, 30 Vimercate Italy Email: sergio.belotti@alcatel-lucent.com Dimitri Papadimitriou Alcatel-Lucent Copernicuslaan 50 Antwerpen B-2018 Belgium Email: dimitri.papadimitriou@alcatel-lucent.be Ceccarelli, et al. Expires January 8, 2013 [Page 11]