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