CCAMP Working Group Eric Mannie (Ebone) Internet Draft Dimitri Papadimitriou (Alcatel) Expiration Date: December 2001 June 2001 GMPLS Signaling Extension to Control the Conversion between Contiguous and Virtual Concatenation for SONET and SDH. draft-mannie-ccamp-gmpls-concatenation-conversion-00.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. 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. 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 E. Mannie et. al. 1 draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt June, 2001 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. However, much 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 that issue, conversion between contiguously concatenated signals and virtually concatenated signals can be used (and vice versa). ITU-T G.783 2001 (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. 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. At the opposite end of the spectrum 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. In all cases the 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. 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]. E. Mannie et. al. Internet-Draft December 2001 2 draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt June, 2001 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 is defined hereafter as a way to negotiate dynamically the use of contiguous to virtual concatenation converters, and vice versa. It tends to maximize the use of virtual concatenation in a network. This extension is only applicable to VC-4-Xc signals as defined in ITU-T G.783. It is not in the scope of this signaling specification to define how the conversion is done in the data plane. This document will be extended with the adequate SONET references in the next release. 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 it. 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 on 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. If 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 downstream to upstream direction, able to convert from virtual to contiguous. 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 E. Mannie et. al. Internet-Draft December 2001 3 draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt June, 2001 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 reaches the source itself. In that case, the signal is indeed contiguously concatenated end-to-end. Indeed there are five possible cases and all were 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 the closest converter to the source and the closest invert converter to the destination. The routing algorithm can or cannot compute a route taking converters into consideration. Moreover, there is no need to indicate explicitly in the signaling which node must convert in which way. 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 supported (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 and/or arbitrary contiguous concatenation flags. These last two flags allow knowing the type of contiguous concatenation to apply in each contiguously concatenated part of the network. Note that they donÆt 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 and multiplier features 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. 3. Acknowledgments Valuable comments and input were received from Alexandre Geyssens, Xavier Neerdaels and Philippe Noel. E. Mannie et. al. Internet-Draft December 2001 4 draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt June, 2001 4. Security Considerations This draft introduces no new security considerations to [GMPLS- SONET-SDH]. 5. References [GMPLS-LDP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling - CR-LDP Extensions", Internet Draft, draft-ietf-mpls-generalized-cr-ldp-02.txt, April, 2001. [GMPLS-SIG] Ashwood-Smith, P. et al, "Generalized MPLS - Signaling Functional Description", Internet Draft, draft-ietf-mpls-generalized-signaling-02.txt, February 2001. [GMPLS-RSVP] Ashwood-Smith, P. et al, "Generalized MPLS Signaling - RSVP-TE Extensions", Internet Draft, draft-ietf-mpls-generalized-rsvp-te-02.txt, April, 2001. [GMPLS-ARCH] E. Mannie Editor, "GMPLS Architecture", Internet Draft, draft-many-gmpls-architecture-00.txt, March, 2001. [GMPLS-SONET-SDH] E. Mannie Editor, "GMPLS Extensions for SONET and SDH Control", Internet Draft, draft-ietf-ccamp-gmpls-sonet-sdh-01.txt, June, 2001. [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 EBONE Terhulpsesteenweg 6A 1560 Hoeilaart - Belgium Phone: +32 2 658 56 52 Mobile: +32 496 58 56 52 Fax: +32 2 658 51 18 Email: eric.mannie@ebone.com E. Mannie et. al. Internet-Draft December 2001 5 draft-mannie-ccamp-gmpls-concatenation-conversion-00.txt June, 2001 Dimitri Papadimitriou Senior R&D Engineer - Optical Networking Alcatel IPO-NSG Francis Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 Email: Dimitri.Papadimitriou@alcatel.be E. Mannie et. al. Internet-Draft December 2001 6