CCAMP Working Group Eric Mannie (KPNQwest) Internet Draft Dimitri Papadimitriou (Alcatel) Expiration Date: November 2002 May 2002 GMPLS Signaling Extension to Control Conversion between Contiguous and Virtual Concatenation for SONET and SDH. draft-mannie-ccamp-gmpls-concatenation-conversion-01.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." To view the current status of any Internet-Draft, please check the "1id-abstracts.txt" listing contained in an Internet-Drafts Shadow Directory, see http://www.ietf.org/shadow.html. Abstract This document is a companion to the GMPLS extensions for SONET and SDH control [GMPLS-SONET-SDH]. It defines a way to control and negotiate the use of converters between contiguous and virtual concatenation in SONET and SDH networks. A new flag in the Requested Contiguous Concatenation (RCC) field is proposed for that purpose. Conventions used in this document: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. 1. Introduction When SONET/SDH LSPs are established and removed dynamically using GMPLS signaling, some fragmentation of the SONET/SDH multiplex at each interface can happen. For instance, it is possible to have some free timeslots (holes) between larger set of allocated timeslots. E.Mannie et al. Internet Draft û November 2002 1 draft-mannie-ccamp-gmpls-concatenation-conversion-01.txt May 2002 These holes cannot be used to route larger contiguously concatenated signals. This problem is expected to happen in a network where many non- concatenated and contiguously concatenated signals of different sizes are dynamically established and removed. This issue is similar to the partitioning that could happen on a hard disk. After some time, the fragmentation could be so high that it could be required to re-arrange locally the usage of the timeslots between two nodes. This process means that a local bridge and roll of circuits must be done. To avoid such a problem, the ideal solution is to use only virtual concatenation allowing inherently re-using the holes. In that case, the X individuals VC-4 signals constitute a VC-4-Xv. The individuals VC-4's can be routed over different routes within the constraints given by [G.707]. The concatenation information is contained in the POH and is only required at the path termination equipment, i.e. virtual concatenation does not require any functionality at intermediate network elements. However, most SONET/SDH equipmentÆs donÆt support virtual concatenation at all. For instance, this is the case of most SONET/SDH interfaces on IP routers. These interfaces being almost exclusively contiguously concatenated interfaces (even not channelized). To solve this issue, conversion between contiguously concatenated signals and virtually concatenated signals can be used (and vice versa). [G.783] Section 12.5.2 specifies how to convert a contiguously concatenated VC-4-Xc to a virtually concatenated VC-4- Xv (and vice versa) through the use of the S4 interworking function. A contiguously concatenated signal can be converted to a virtually concatenated signal at the ingress of a cloud. The inverse conversion can take place at the egress of the cloud. Ideally, such converters should be available as close as possible to the nodes that are only capable of contiguous concatenation. However, in a heterogeneous network one cannot expect that such converters will be available everywhere where they will be needed. Normally, the conversion capability should be advertised in routing protocols to allow finding a path with the right ingress and egress converters. It will become complex if the ingress converter belongs to one routing domain while the egress converter belongs to another routing domain. On the other hand, one could consider that such conversion capability can be available on a hop-by-hop basis at some hops. In that case, the routing protocols and routing algorithms donÆt need to take any new information into consideration. A path is computed independently of the knowledge of converters and the bandwidth optimization is done when available, on a hop-by-hop basis. E.Mannie et al. Internet Draft û November 2002 2 draft-mannie-ccamp-gmpls-concatenation-conversion-01.txt May 2002 In all cases the simple signaling extension defined in this document allows to negotiate the use of conversion between neighbors. The rules defined hereafter must be applied when using this extension. 2. Control of conversion between contiguous and virtual concatenation This section defines the following optional extension flag for the Requested Contiguous Concatenation (RCC) field of section 2.1 of [GMPLS-SONET-SDH]: Flag 3 (bit 3): Adaptable contiguous concatenation. This flag allows an upstream node to signal to a downstream node that it supports the adaptable contiguous concatenation type. This type of concatenation does not correspond to any new type of concatenation but is simply defined hereafter as a code-point to allow to negotiate dynamically the use of contiguous to virtual concatenation converters, and vice versa. The mechanism defined in this document intends to maximize the use of virtual concatenation. In addition, it allows negotiating the use of virtual concatenation between the source and destination systems. The use of virtual concatenation itself can in turn be controlled by LCAS [G.7042] for instance. This extension is only applicable to VC- 4-Xc signals as defined in [G.783]. It is not in the scope of this signaling specification to define how the conversion is done in the transport plane. The first LSR in the path supporting the conversion on its output interface uses this extension to signal it (i.e. it sets the flag). The flag is forwarded downstream with the adequate signaling message until it reaches the destination. The first LSR may be the source LSR itself, if it supports virtual concatenation and if it wants to negotiate its use with the destination. The destination answers positively with the adequate list of labels if it supports virtual concatenation. The same is done in the upstream direction at each hop, until it reaches the LSR providing the conversion function (converter). Upstream of the converter, a unique label is used until it reaches the source. The signal is thus transported contiguously concatenated until it reaches the first converter over the path and then it becomes virtually concatenated until it reaches the destination. Eventually, the positive answer reaches the source itself. In that case, the signal is indeed virtually concatenated end-to-end. In that case, this extension allows to request a contiguously concatenated signal, and to negotiate the use of virtual concatenation end-to-end. If supported, the virtual concatenation will be used instead of the contiguous concatenation. E.Mannie et al. Internet Draft û November 2002 3 draft-mannie-ccamp-gmpls-concatenation-conversion-01.txt May 2002 If virtual concatenation is not supported by the destination, a single label is sent upstream by the destination. The same operation is done upstream at each hop, until it reaches the first node, in the upstream direction, able to convert from contiguous (single label) to virtual (list of labels). If such a node is found, a positive answer is sent upstream until it reaches the node that has set up the flag. This node can be a contiguous to virtual converter. In this case, the signal will be transported contiguously concatenated from the source to the ingress converter, then as virtually concatenated from the ingress converter to the egress converter, and then finally as contiguously concatenated from the egress converter to the destination. Eventually, the negative answer (single label) reaches the source itself. In that case, the signal is indeed contiguously concatenated end-to-end. Note that a converter having received the flag set from an upstream node MUST NOT convert from virtual to contiguous in the upstream direction (because there is upstream another converter closer to the source). Indeed, there are five possible cases and all are covered by the mechanisms described here before: 1. Contiguous concatenation end-to-end. 2. Contiguous followed by virtual concatenation. 3. Virtual followed by contiguous concatenation. 4. Contiguous, then virtual then contiguous concatenation. 5. Virtual concatenation end-to-end. This simple scheme triggers finding and using of the closest converter to the source and the closest invert converter to the destination. The routing algorithm does not need to compute a route taking converters into consideration (but it may for additional efficiency). Moreover, with this mechanism there is no need to indicate explicitly in the signaling which node must convert in which way, the most appropriate converter being selected automatically. Note that simply using the virtual concatenation indication allows neither to change the concatenation type on the fly, nor negotiating the concatenation type end-to-end. Adaptable contiguous concatenation is a way to advertise that contiguous concatenation is asked (most frequent case) but that virtual concatenation could be done instead (less frequent case). The adaptable contiguous concatenation flag MUST be used together with standard contiguous concatenation flags. These flags allow knowing the type of contiguous concatenation to apply in each contiguously concatenated part of the network. Note that they donÆt E.Mannie et al. Internet Draft û November 2002 4 draft-mannie-ccamp-gmpls-concatenation-conversion-01.txt May 2002 need to be the same in case 4, each contiguous segment can be effectively in a different type. This extension is compatible and can be combined with the virtual concatenation of contiguously concatenated signals [GMPLS-SONET-SDH- EXT] and the multiplier feature defined in [GMPLS-SONET-SDH]. If the result of the concatenation negotiation is a virtual concatenation in some part of the network, then the number, order and nature of the corresponding SONET/SDH timeslots pointed by the labels unambiguously indicates the result of the negotiation. Note that the mechanism and extension defined in this document have nothing to do with LCAS, and can be used with or without LCAS. 3. Acknowledgments Valuable comments and input were received from Alexandre Geyssens, Xavier Neerdaels and Philippe Noel. 4. Security Considerations This draft introduces no new security considerations to [GMPLS- SONET-SDH]. 5. References [G.707] "Network node interface for Synchronous Digital Hierarchy (SDH)", Recommendation G.707, ITU-T, 10/2000. [G.783] "Characteristics of Synchronous Digital Hierarchy (SDH) equipment functional blocks", Recommendation G.783, ITU-T, 10/2000. [G.7042] "Link Capacity Adjustment Scheme (LCAS) for virtual concatenated signals", Recommendation G.7042, ITU-T, 11/2001. [GMPLS-SIG] L.Berger et al, "Generalized MPLS - Signaling Functional Description", Internet Draft, draft-ietf- mpls-generalized-signaling-08.txt, April 2002. [GMPLS-LDP] L.Berger et al, "Generalized MPLS Signaling - CR-LDP Extensions", Internet Draft, draft-ietf-mpls- generalized-cr-ldp-06.txt, April 2002. [GMPLS-RSVP] L.Berger et al, "Generalized MPLS Signaling - RSVP-TE Extensions", Internet Draft, draft-ietf-mpls- generalized-rsvp-te-07.txt, April 2002. [GMPLS-ARCH] Mannie, E., Papadimitriou D. et al., "GMPLS Architecture", Internet Draft, draft-ietf-ccamp-gmpls- architecture-02.txt, March 2002. E.Mannie et al. Internet Draft û November 2002 5 draft-mannie-ccamp-gmpls-concatenation-conversion-01.txt May 2002 [GMPLS-SONET-SDH] Mannie, E., Papadimitriou D. et al., "GMPLS Extensions for SONET and SDH Control", Internet Draft, draft-ietf-ccamp-gmpls-sonet-sdh-05.txt, May 2002. [GMPLS-SONET-SDH-EXT] Mannie, E., Papadimitriou D. et al., "GMPLS extensions to control non-standard SONET and SDH features", Internet Draft, draft-ietf-ccamp-gmpls- sonet-sdh-extensions-03.txt, April 2002. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119. [RFC2210] Wroclawski, J., "The Use of RSVP with IETF Integrated Services," RFC 2210, September 1997. 6. Authors' Addresses Eric Mannie (KPNQwest) Terhulpsesteenweg 6A 1560 Hoeilaart - Belgium Phone: +32 2 658 5652 Email: eric.mannie@kpnqwest.com Dimitri Papadimitriou (Alcatel) Francis Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 Email: dimitri.papadimitriou@alcatel.be E.Mannie et al. Internet Draft û November 2002 6 draft-mannie-ccamp-gmpls-concatenation-conversion-01.txt May 2002 Full Copyright Statement "Copyright (C) The Internet Society (date). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." E.Mannie et al. Internet Draft û November 2002 7