CCAMP Working Group E. Mannie (Ebone) Informational Draft D. Papadimitriou (Alcatel) Expiration Date: May 2002 November 2001 GMPLS Interworking between Sonet and SDH draft-papadim-ccamp-gmpls-sonet-sdh-interwork-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 to control SONET/SDH networks as defined in [GMPLS-SONET-SDH], [GMPLS-SONET- SDH-EXT] and [GMPLS-SONET-SDH-RTG]. They define the SONET and SDH technology specific information needed when using GMPLS signaling. This informational memo details the GMPLS signalling and some routing specific considerations to control the interworking between SONET and SDH networks. It results from this, that interworking issues from the control plane viewpoint are well covered by the current definition of the Sonet/SDH extensions to the GMPLS protocol suite. 1. Introduction Generalized MPLS (GMPLS) [GMPLS-ARCH] extends MPLS from supporting packet (Packet Switching Capable - PSC) interfaces and switching to include support of four new classes of interfaces and switching: Layer 2 Switch Capable (L2SC), Time-Division Multiplex (TDM), Lambda Switch Capable (LSC) and Fiber-Switch Capable (FSC). Informational Draft û Expires May 2002 1 draft-papadimitriou-ccamp-gmpls-sonet-sdh-interwork-00.txt Nov 2001 A functional description of the extensions to MPLS signaling needed to support these new classes of interfaces and switching is provided in [GMPLS-SIG]. [GMPLS-RSVP] describes RSVP-TE specific formats and mechanisms needed to support all four classes of interfaces, and CR-LDP extensions can be found in [GMPLS-LDP]. [GMPLS-SONET-SDH] and [GMPLS-SONET-SDH-EXT] present details that are specific to SONET/SDH. Per [GMPLS-SIG], SONET/SDH specific parameters are carried through the signaling protocol in traffic parameter specific objects. This informational memo describes GMPLS signaling and some routing considerations to control interworking between SONET and SDH. 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. SONET/SDH Interworking This section describes how SDH and SONET can interwork at the transport plane level. SONET networks are based on STS-1 frames while SDH networks are based on STM-1 frames. An STS-1 frame is composed by a transport overhead (corresponding to the SDH RS and MS overhead) and a SPE (corresponding to the SDH VC-3 plus two columns of fixed stuff). There is no equivalent for an STS-1 frame in the SDH standard, but an STS-1 frame would correspond to an SDH frame build with a single AU-3. Three major different ways of providing the interworking capabilities are presented hereafter: 1. Interworking between VC-4 and STS-1 SPE 2. Interworking between VC-4-Nc and STS-(3*N)c SPE (SONET) 3. Interworking between VC-4 and STS-1 SPE lower order signals Interworking between SDH and SONET may be needed for different reasons. For instance, it may happen between North American and European operators in order to provide connectivity between them. In these cases, interworking occurs between a SONET routing domain and an SDH routing domain, and requires an inter-domain routing protocol for capability exchange between these domains (it is, therefore, not in the scope of this document to specify the corresponding extensions). However, interworking may also be useful for a single operator providing both SDH and SONET services in the same routing domain. In this case, the routing domain may or may not be divided into areas. We assume that a SDH/SONET gateway can be an intra-area node or an area border node. First consider the case where the domain is divided into areas. For instance, if one OSPF area is SONET based, and the backbone area is SDH based, different area border nodes between these two areas could Informational Draft û Expires May 2002 2 draft-papadimitriou-ccamp-gmpls-sonet-sdh-interwork-00.txt Nov 2001 advertise different interworking capabilities. For a source node to be able to compute a source route, it is important that it be able to compute a source route through a border node providing the adequate interworking capabilities. Next consider the case where there are no areas, and a flat OSPF or IS-IS routing domain is used, mixing both SDH and SONET types of network. No inter-area exchange of information needs to take place. This is the simplest case where interworking considerations can be applied without any additional routing considerations from the one covered in [GMPLS-SDH-SONET-RTG]. A node capable of acting as a SDH/SONET gateway should advertise its particular interworking capabilities to every other node belonging to the same routing domain. In the scope of this memo, a SDH/SONET gateway node includes at least one Sonet and one SDH interface. It is capable to terminate both the Section/RS Overhead and Line/MS Overhead on Sonet/SDH interface, respectively. Pointer processing follows the rules defined in ITU-T G.707 and ANSI T1.105. The SDH/SONET interworking scenarios supported in this specification cover: - Interworking between VC-4 and STS-1 SPE - Interworking between VC-4-Nc and STS-(3*N)c SPE - Interworking between VC-4 and STS-1 SPE lower order signals Note: section 3.2 covers interworking between VC-4-Xc and STS-3c-Xc Contiguous concatenation issues 2.1 Interworking between VC-4 and STS-1 SPE In one direction, from STS-1 to STM-1 (interface level), this interworking is accomplished by extracting the SPE of an STS-1, transforming the SPE into a VC-3 via pointer processing and the removal of two columns of fixed stuff bytes, and processing the VC-3 via the TU-3/TUG-3/VC-4/AUG route as shown below. In the other direction, from STM-1 to STS-1, exactly the opposite occurs. ->STM-1 | |x1 | ->VC4-->AU4-->AUG- | |x3 | STS-1- ->TU3-->TUG3- | | | |x1 | | -SPE--transf-->VC3- Informational Draft û Expires May 2002 3 draft-papadimitriou-ccamp-gmpls-sonet-sdh-interwork-00.txt Nov 2001 Figure: STS-1 to STM-1 mapping through TU-3. Using this capability, for instance, three independent DS-3 signals, each transported by a SONET STS-1 signal, can be multiplexed and transported in one single STM-1 signal. Alternatively, the VC-3 could be transported via the AU-3/AU-3 route as described below. Again three independent DS-3 signals transported over SONET can be transported over SDH. ->AUG->STM-1 | |x3 | STS-1- -->AU3-- | | | |x1 | | -SPE--transf-->VC3- Figure: STS-1 to STM-1 mapping through VC-3/AU-3. Note that if a single DS-3 has to be transported end-to-end, it can imply on the SDH side that a whole VC-4 needs to be equipped to the end, even if the two other VC-3 components are not used. Ideally, the routing algorithm should know the details of both the SDH and the SONET clouds in order to find the path that minimizes the number of SDH VC-3s that will not be used (i.e. to minimize internal fragmentation of VC-4s due to the interworking). SDH networks support both VC-3 and VC-4, however SDH mainly uses VC- 4s. Therefore a SONET signal must be mainly demultiplexed, transformed and remultiplexed within an SDH AUG via the TU-3/TUG- 3/VC-4/AU-4 route. 2.2 Interworking between VC-4-Nc and STS-(3*N)c SPE Interworking between VC-4 and STS-3c SPE is simpler to implement since the two frames have the same structure. In practice, a VC-4-Nc will be mapped to an STS-(3*N)c and vice versa. The standard SONET concatenation only allows STS-Nc multiplexing where N is a multiple of 3. This helps with SDH interworking. Likewise, interworking between VC-4-Nc and STS-(3*N)c is relatively simple to implement. Note however than certain interworking issues still remain due to overhead processing differences. 2.3 Interworking between VC-4 and STS-1 SPE Lower Order Signals Interworking is also possible between the SDH TUG-2, TU-11, TU-12 or TU-2 and respectively the SONET VT Group, VT1.5, VT2 and VT6. Since the corresponding sub-signals have the same structure, this interworking should be straightforward. Note however that a SONET VT-3 (SPE) has no equivalent in the SDH world. Informational Draft û Expires May 2002 4 draft-papadimitriou-ccamp-gmpls-sonet-sdh-interwork-00.txt Nov 2001 3. Generalized MPLS Signalling This document specifies the GMPLS interworking between an SDH cloud and a SONET cloud through the use of gateways. A gateway is an node that has to transform the transport plane, do some light translation in the signaling and that may have to adapt some link state advertisements. IP addresses are considered here as unique in the whole network. We assume hereafter that the same GMPLS profile is implemented on both sides of each gateway and that GMPLS is used end-to-end. Consequently, only a few technology specific fields need to be translated in the GMPLS signaling when using such a gateway. Note that there is no translation required for the labels since they are purely local per interface. Consequently there is no label interworking issue. 3.1 Signaling Aspects To open an SDH or SONET circuit a signaling message is sent from the source to the destination in an RSVP-TE Path or CR-LDP Label Request message. This signaling message transports a Generalized Label Request Object/TLV and a SONET/SDH Traffic Parameters Object/TLV. The LSP Encoding Type included within the Generalized Label Request indicates either SDH or SONET in our case. A gateway has to translate this field from value SDH ITU-T G.707 (5) to value Sonet ANSI T1.105 (6) and vice versa. The SONET/SDH Traffic parameters contains multiple fields, some of them may not be used. One of these fields is the Signal Type which indicates the base type of signal being considered. The Signal Type values are defined identically for both SDH and SONET to simplify interworking issues. For a basic request including an elementary Signal Type on which no concatenation and no transparency is applied, no Signal Type transformation is needed. Moreover, the Multiplier field doesn't require any modification. There is however one restriction, this document doesn't cover SONET VT-3 interworking since it has no equivalent in SDH. Concatenation and transparency are discussed in the next sub-sections. 3.2 Contiguous Concatenation [GMPLS-SONET-SDH] and [GMPLS-SONET-SDH-EXT] define the following optional flags for the Requested Contiguous Concatenation (RCC) field: Flag 1 (bit 1): Standard Contiguous Concatenation Flag 2 (bit 2): Arbitrary Contiguous Concatenation Informational Draft û Expires May 2002 5 draft-papadimitriou-ccamp-gmpls-sonet-sdh-interwork-00.txt Nov 2001 If contiguous concatenation is requested in the Traffic Parameter Object/TLV, this memo allows only the interworking between a VC-4- Xc and an STS-3c-Xc using the Standard Contiguous Concatenation. In this case, the Signal Type, RCC and NCC fields do not have to be modified. The transport plane transformation is done as explained in section 2.2. All other cases of contiguous concatenations, in particular the arbitrary one, are for further study. 3.3 Transparency The Transparency field (defined as a vector of flag) indicates within precisely which fields in these SONET/SDH overheads must be delivered unmodified at the other end of the LSP. An ingress node requesting transparency will pass these overhead fields that must be delivered to the egress node without any change. From the ingress and egress nodes point-of-views, these fields must be seen as unmodified. Transparency is not applied at the interfaces with the initiating and terminating nodes, but is only applied between intermediate nodes. Notice that Transparency is only applicable when frame types of signal are used. They are some difference in the overheads between SONET and SDH. Detailed explanations concerning the mapping between the two is not in the scope of this specification. The effect of these differences on the Transparency field is left for further study. 3.4 Virtual Concatenation This section will include in a further release the Virtual Concatenation interworking issues. In particular when the ingress (egress) node include an SDH VC capable interface and the egress (ingress, respectively) a Sonet VC capable interface. 4. Interworking Rules This section summarizes the interworking rules: - LSP Encoding Type: value change from LSP Encoding Type value 5 to 6 (when flowing from SDH to Sonet) and from value 6 to 5 (when flowing from Sonet to SDH) - Switching Type: no value change since a single TDM value is defined for both Sonet and SDH switching - Signal Type: no value change since SDH Signal Types values are mapped to their Sonet equivalent - Transparency: in principle no particular rule however, hardware specific implementation may generate some restrictions in Informational Draft û Expires May 2002 6 draft-papadimitriou-ccamp-gmpls-sonet-sdh-interwork-00.txt Nov 2001 particular when using J0 and MS/Line K1/K2 transparency fields - Contiguous Concatenation: no specific issue to consider since the gateway terminates the overhead providing the needed functions to enable contiguous concatenation interoperability - Virtual Concatenation: FFS 5. Security Considerations This draft introduces no new security considerations to [GMPLS- SONET-SDH]. 6. References 1. [GMPLS-SIG] P.Ashwood-Smith, L.Berger et al, ôGeneralized MPLS - Signaling Functional Descriptionö, Internet Draft, Work in progress, draft-ietf-mpls-generalized-signaling-06.txt, October 2001. 2. [GMPLS-LDP] P.Ashwood-Smith, L.Berger et al, ôGeneralized MPLS Signaling - CR-LDP Extensionsö, Internet Draft, Work in progress, draft-ietf-mpls-generalized-cr-ldp-04.txt, July 2001. 3. [GMPLS-RSVP] P.Ashwood-Smith, L.Berger et al, ôGeneralized MPLS Signaling - RSVP-TE Extensionsö, Internet Draft, Work in progress, draft-ietf-mpls-generalized-rsvp-te-05.txt, October 2001. 4. [GMPLS-SONET-SDH] E. Mannie (Editor) et al, ôGMPLS extensions for SONET and SDH controlö, Internet Draft, Work in progress, draft-ietf-ccamp-gmpls-sonet-sdh-02.txt, October 2001. 5. [GMPLS-SONET-SDH-EXT] E. Mannie (Editor) et al, ôGMPLS extensions for SONET and SDH control û Extensionsö, Internet Draft, Work in progress, draft-ietf-ccamp-gmpls-sonet-sdh- extensions-00.txt, October 2001. 6. [GMPLS-SONET-SDH-CCV] E. Mannie and D. Papadimitriou, ôGMPLS Signaling Extension to Control the Conversion between Contiguous and Virtual Concatenation for SONET and SDHö, Internet Draft, Work in progress, draft-ietf-ccamp-gmpls-concatenation-conversion- 00.txt, July 2001. 7. [GMPLS-SONET-SDH-RTG] E. Mannie et al, ôExtensions to OSPF and IS-IS in support of MPLS for SDH/SONET Controlö, Internet Draft, Work in progress, draft-mannie-mpls-sdh-ospf-isis-01.txt, July 2001. 8. [GMPLS-ARCH] E. Mannie (Editor) et al, ôGeneralized MPLS Architectureö, Internet Draft, Work in progress, draft-ietf-ccamp- gmpls-architecture-00.txt, June 2001. 9. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels," RFC 2119. Informational Draft û Expires May 2002 7 draft-papadimitriou-ccamp-gmpls-sonet-sdh-interwork-00.txt Nov 2001 7. Authors Addresses Eric Mannie Ebone (GTS) Terhulpsesteenweg 6A 1560 Hoeilaart - Belgium Phone: +32 2 658-5652 Email: eric.mannie@ebone.com Dimitri Papadimitriou Alcatel Francis Wellesplein 1, B-2018 Antwerpen, Belgium Phone: +32 3 240-8491 Email: Dimitri.Papadimitriou@alcatel.be Informational Draft û Expires May 2002 8