Internet Draft
Network Working Group Eric Mannie
Internet Draft GTS Network Services
Expiration Date: September 2000
March 2000
MPLS for SDH control
draft-mannie-mpls-sdh-control-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."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This document is an attempt to specify how MPLS could be used to control the
establishment of SDH paths. It identifies the elements that could be switched in
SDH, proposes a way to build labels for SDH ôintelligentö switching and
discusses several problems. Annexes A and B are intended to specify how to
support this specification using CR-LDP and TE-RSVP.
This specification covers mainly the following SDH aspects:
- STM-N and lower order signals switching.
- Virtual and contiguous concatenation.
- STM-0 signal.
- SDH interconnection (VC-3, TUG-2, VC-11).
- VC-11 to VC-12 conversion.
- Multiplex identification (by extending the (K, L, M) notation).
- Payload identification.
1. Introduction
1.1. Specification of Requirements
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 RFC 2119 [3].
1.2 Abbreviations
ADM Add-Drop Multiplexer
AIS Alarm Indication Signal
AU-n Administrative Unit-n
AUG Administrative Unit Group
DCC Data Communication Channel
LSP Label Switched Path
MS-AIS Multiplex Section Alarm Indication Signal
MSOH Multiplex Section Overhead
MPLS Multiprotocol Label Switching
PDH Plesiochronous Digital Hierarchy
POH Path Overhead
RSOH Regenerator Section Overhead
SDH Synchronous Digital Hierarchy
SOH Section Overhead
STM(-N) Synchronous Transport Module (-N)
TU-n Tributary Unit-n
TUG(-n) Tributary Unit Group (-n)
VC-n Virtual Container-n
2. SDH Intelligent control plane
The goal of this document is to introduce how parts of MPLS could be used as a
possible SDH control plane to dynamically establish, maintain and close SDH
paths. The objective is to provide at least the same kind of SDH services as
provided today, but using signaling instead of provisioning to establish these
paths. This will allow operators to propose new services, allowing clients to
create SDH paths on-demand, in real-time, trough the provider network.
One constraint is that we should be as much transparent as possible at the SDH
level. From an SDH provider point of view, it is obvious that the path overhead
cannot be touched since it belongs to the client. It is also a good practice to
avoid touching the section overhead, since it could imply complex changes in
existing hardware. This document does not imply any modification of the SDH
overheads.
This specification is based on the ITU-T G.707 (3/96) Recommendation. This
Recommendation is indeed a merged revised version of Recommendations G.707,
G.708 and G.709 that were published in 1993. This specification is mainly based
on the vocabulary defined in G.707 (3/96). It is the intention of the author to
extend this document to cover the SONET specification in the next version.
SDH defines a multiplexing structure that can be controlled by MPLS. In the
following, we will refer to this multiplexing structure as the SDH multiplex.
This multiplex should be seen hierarchically from the MPLS point of view. The
SDH layer cannot be simply viewed as flat, otherwise it will limit the scope of
services that can be provided. In the hierarchical approach, MPLS tunnels are
used to dynamically and hierarchically control the SDH multiplexing. For
example, one unstructured VC-4 LSP may be established between two nodes, and
then later lower order LSPs (e.g. VC-12) are created in that higher order LSP.
An SDH Path is the logical connection between the point at which a signal is
assembled into its virtual container, and the point at which it is disassembled
from the virtual container. From the MPLS point of view, a Path is seen as an
LSP.
Different type of synchronous and asynchronous signals can be transported by SDH
and we have to decide what are the signals that we want to control through MPLS.
In a first approach we will consider the following signals: VC-4-Xc (for
instance at line rates: STM-64, STM-16, STM-4), VC-4 (STM-1 rate); and G.702
tributary signals such as VC-3, VC-2, VC-2-mc, VC-12 and VC-11. In addition, the
STM-0 (51 840 kbit/s) line rate is also covered. This next version of this
specification will cover sub-STM-0 line signals as well.
In addition, these signals may transport different types of information (e.g.
ATM, maintenance signal, asynchronous data, etc), this is indicated by the C2
byte of the POH (Path OverHead) for VC-4-Xc, VC-4 and VC-3 signals; and in a
field of the V5 byte of the POH for the VC-2, VC-12 and VC-11 signals. That kind
of information should be passed along between two nodes using MPLS signaling
since it will allow an end node to know for what purpose is targeted a signal.
All these signals are point-to-point paths between an ingress SDH node and an
egress SDH node. Such a border node may be either, a Terminal Multiplexer (TM)
or an Add-Drop Multiplexer (ADM). Other kinds of connections, e.g. point-to-
multipoints are FFS.
Let a SDH TM, ADM or cross-connect be called an SDH-LSR (SDH Label Switched
Router). An SDH path for a given signal between two SDH edge nodes becomes now
an MPLS LSP between the two edge SDH-LSRs.
3. Basic operations:
MPLS was mainly thought to control asynchronous technologies like IP, on the
contrary SDH is a synchronous technology. In the following we will not consider
that each SDH ôframeö has its own label and that we have to switch frames
individually, but rather that the unit to switch is an individual SDH signal. A
label is being associated with each given signal.
The payload of an STM-1 frame doesnÆt contain fully a complete unit of user
data. This user data is indeed contained in a virtual Container (VC) that is
allowed to float over two contiguous frames. A pointer in the Section Overhead
(SOH) indicates the beginning of the VC in the payload. It results that all
these frames are inter-related since each consecutive pair may share a common
virtual container. From the MPLS point of view, they cannot be considered as
individual frames corresponding to separate flows.
An SDH-LSR will have to identify each possible signal individually per interface
in order to fulfill the MPLS operations. In order to stay transparent we should
not touch the SDH overheads; this is why we do not propose to code any explicit
label in SDH overheads.
This approach is similar to the one considered for lambda switching, except that
it is more complex since SDH defines a multiplexing structure. We have to
identify univocally each possible signal in the SDH multiplex and associate a
label with each one. A multiplex table must be maintained for each interface,
indicating signals that have been allocated and the corresponding label. The way
that this table is implemented is outside of the scope of this document. Note
however, that it could be implemented as a tree or a list, and that not all-
possible labels must have space reserved.
There are two ways to assign labels for signals between two neighbor SDH-LSRs.
First, labels could be allocated completely independently of any SDH semantic;
e.g. labels are just allocated as sequential numbers. In that case, without
having the appropriate binding information, a label does not give any
information about the flow that it represents. From the management and debugging
point of views, it is not easy to match a label with the corresponding signal,
since the label is not coded in the SDH overhead(s).
Specific information elements (IEs) will be needed in the signaling protocol
used to establish the LSP, in order to map a label with the particular signal
type it represents (bandwidth), its position in the SDH multiplex, and the type
of information transported.
For that purpose, we propose a particular signal numbering scheme using the SDH
multiplexing structure used as a naming tree. This will allow identifying
univocally each multiplex entry (signal), i.e. its type and its position. We
will define a notation to identify each multiplex entry and the corresponding
coding. Each multiplex entry will then have a unique value associated. This is
possible since the SDH multiplexing structure is well defined and has a limited
size.
Any label may then be associated with a multiplex entry. However this
specification proposes a more clever way to assign labels, as a possible
extension. We propose to use the multiplex entry value itself as the label
value. Indeed, we add SDH semantic to the label. We will refer to this as being
a multiplex based labeling. It results that simply by viewing the label, one
could directly derive the signal it represents, its position in the SDH
multiplex and even the type of information transported (optional).
4. Hierarchical label allocation:
At one moment in the time, a particular position in the SDH multiplex, may be
used or not (it is free), and it may be a valid position or not, according to
other signals already allocated. A multiplex entry must be interpreted in
relationship with the already allocated multiplex entries.
The fact that two neighbor SDH-LSRs allocates a label for a particular LSP
implies that the corresponding signal will be enabled in the multiplex between
the two SDH-LSRs. When an LSP is removed, the corresponding local label is
considered as released, and the corresponding multiplex space may be re-used. An
MPLS conservative label retention mode must be implemented when using multiplex
based labeling.
For instance, for a downstream-on-demand label allocation, the upstream LSR must
indicate the type of signal it wants to forward (to be detailed). The downstream
SDH-LSR needs to check if such a signal is available in its multiplex and
returns the corresponding label. In the case of multiplex based labeling, the
upstream SDH-LSR is able to easily check if the right type of signal was
allocated by the downstream SDH-LSR just by looking to the label.
The downstream SDH-LSR is indeed applying a straightforward SDH Call Admission
Control (CAC) function based on the space available in the multiplex. Note that
the two SDH-LSRs should have an identical multiplex table, so the upstream SDH-
LSR could even check in its own multiplex table for that particular interface,
if space is available for that signal, before requesting a label.
The two neighbor SDH-LSRs could have a mechanism to periodically check if their
multiplex tables are identical, i.e. fully synchronized. This can be achieved in
different ways, e.g. through the MPLS signaling by exchanging the complete
multiplex tables, or just the list of currently allocated signals (labels). This
capability is FFS. If the neighbors SDH-LSRs discover that their multiplex
tables are not identical, a fault generation should be immediately triggered to
a management station.
Note that since an SDH-LSR may have neighbor relationship at different levels,
the multiplex table that is common between two neighbor SDH-LSRs should be
understood respectively to that relationship. I.e. two neighbor SDH-LSRs should
compare only the list of LSPs they negotiated together.
------SDH-LSR1 <---------------(1)-------------> SDH-LSR4------
I I
I-----> SDH-LSR2 <--------> SDH-LSR3 <----I
Figure 1.
For instance, in figure 1, SDH-LSR4 and SDH-LSR3 may have an unstructured VC-4
negotiated together, while SDH-LSR4 and SDH-LSR1 may have negotiated a VC-11 in
that VC-4 (1). If SDH-LSR4 and SDH-LSR3 exchange their multiplex tables, SDH-
LSR4 must ensure to just send the view that SDH-LSR3 has of the multiplex. It
results that the multiplex table should maintain views.
5. Multiplex entry naming:
The multiplexing structure defined in recommendation G.707 figure 6-1, extended
to support STM-0 frames (such as described in G.708, figure 6) will be used as
the basic reference to identify the signals. It defines indeed a bi-rooted tree,
whose the two possible roots are either an STM-N or an STM-0; and whose leafs
are the signals that can be transported. This tree will be used as a naming tree
to create unique multiplex entry names as described later. This naming will
identify at the same time the type of signal and its position in the multiplex.
xN x1
STM-N<----AUG<----AU-4<----VC4<------------------------------C-4
^ ^
I x3 I x3
I I x1
I -----TUG-3<----TU-3<----VC-3<----I
----I ^ C-3
STM-0<--------AU-3<--------VC-3<--- I -----------------------I
^ I
I x7 I x7
I I x1
-----TUG-2<----TU-2<----VC-2<----C-2
^ ^
I I x3
I I------TU-12<---VC-12<---C-12
I
I x4
I---------TU-11<---VC-11<---C-11
Figure 2: Naming tree.
>From the SDH switching point of view, the possible leaves of that tree are VC-4,
VC-3, VC-2, VC-12 or VC-11. According to the multiplex structure there is a
maximum of 1 * VC-4, 3 * VC-3, 21 * VC-2, 63 * VC-12 or 84 * VC-11 in one STM-1;
and there is a maximum of 1 * VC-3, 7 * VC-2, 21 * VC-12 or 28 * VC-11 in one
STM-0. Of course different VCs may be combined according to the combination
rules of the SDH multiplex.
A maximum of 172 (1+3+21+63+84) different signals may be identified in one STM-
1, and a maximum of 57 (1+7+21+28) different signals may be identified in one
STM-0. Some of them are incompatible since they use the same physical space,
however we will give a unique name to each of them. For that purpose we will
extend the well-know numbering scheme defined in G.707 section 7.3, i.e. the (K,
L, M) numbering.
N STM-1 signals may be interleaved together to form an STM-N. It results that we
must identify the STM-1 that is itself decomposed in sub-signals. The SDH
concatenation will be treated later in a separate section.
Note: Sub STM-0 signals (G.708) will be described in the next version of this
specification. It will mainly consist in an extension of the multi-rooted tree.
5.1 Multiplex entry notation:
The following hierarchical multiplex entry notation is proposed:
(S, U, K, L, M) or S.U.K.L.M (in dot notation)
S: 0 -> N : denotes an STM-0 signal or the index of an STM-1 signal.
U: 0 -> 4 : index of the Administrative Unit (AU).
K: 0 -> 4 : index denoting the content of a VC-4.
L: 1 -> 8 : index denoting the content of a TUG-3 or VC-3.
M: 0 -> 8 : index denoting the content of a TUG-2.
Each letter indicates a possible branch number starting at the parent node in
the naming tree. Branches are considered as numbered starting from the high of
the figure, the numbering starts normally at 1 (0 is used to indicate an
exception).
1) S indicates an STM-0 signal or is the index of a particular STM-1 signal. S=0
indicates an STM-0, S=1 indicates the first STM-1 and S=N indicates the last
STM-1 signal of the multiplex. STM-1s may be interleaved together, but an STM-0
is never interleaved or concatenated with something else (to check).
2) U indicates a specific VC inside a given STM-1. U=1 indicates a single VC-4,
while U=2->4 indicates a specific VC-3 inside the given STM-1. It is not
meaningful for STM-0 and must be 0 in that case.
3) K indicates possible branches of a VC-4. It is not meaningful for the VC-3
multiplexing and must be 0 in that case. K=1 indicates that the VC-4 is not
further sub-divided. K=2->4 indicates a specific TUG-3 inside the given VC-4. A
multiplex entry name with K=0 denotes a VC-3 multiplexing of an STM-1 (easy to
test and read).
4) L indicates possible branches of either a TUG-3 or a VC-3. In the first case,
L=1 indicates that the TUG-3 is not further sub-divided and contains simply a
VC-3. L=2->8 indicates a specific TUG-2 inside the given TUG-3. In the second
case, L=1 indicates that the VC-3 is not further sub-divided. L=2->8 indicates a
specific TUG-2 inside the given VC-3.
5) M indicates possible branches of a TUG-2. It is not meaningful for an
unstructured VC-4, TUG-3 or VC-3, it must be 0 in that case. M=1 indicates that
the TUG-2 is not further sub-divided and contains simply a VC-2. M=2->4
indicates a specific VC-12 inside the given TUG-2. M=5->8 indicates a specific
VC-11 inside the given TUG-2. A multiplex entry name with M=0 denotes a VC-4 or
VC-3.
For instance, the following notations denote:
1) Example 1: (s>0, 1, 1, O, O)
Denotes the unstructured VC-4 of the s-th STM-1.
2) Example 2: (s>0, 1, l>1, 1, 0)
Denotes an unstructured VC-3 of the l-th TUG-3 of the s-th STM-1.
3) Example 3: (s>0, u>1, 0, 1, 0)
Denotes the u-th unstructured VC-3 of the s-th STM-1.
4) Example 4: (s>0, u>1, 0, l>1, 1)
Denotes the VC-2 of the l-th TUG-2 of the u-th VC-3 of the s-th STM-1.
5) Example 5: (s>0, u>1, 0, l>1, 10, u>1, o, l>1, m>4)
Denotes the m-th VC-11 of the l-th TUG-2 of the u-th VC-3 of the s-th STM-1.
7) Example 7: (s>0, 1, k>1, l>1, m>4)
Denotes the m-th VC-11 of the l-th TUG-2 of the k-th TUG-3 of the s-th STM-1.
8) Example 8: (0, 0, 0, l>1, 1= 64. So we propose to support the two possible coding,
either in the form of (starting signal identifier, length) or in the form of a
list (first signal, second signal, à, last signal).
In both cases, we propose to identify an LSP by the identifier of the first
signal in the concatenation. This identifier indicates implicitly if it is a
concatenation of AU-4s or TU-2s (because it refers to a path in the naming
tree). Moreover, in case of TU-2s it indicates as well if it is in the VC-4
(virtually) or in the VC-3 (contiguous). It results that we do not need to
explicitly code neither the type concatenation, nor the higher order signal in
which the concatenation is made.
Note that SDH imposes a restriction on the virtual concatenation of TUG-2
signals: they must be kept in a single higher order VC-4. Since we consider that
all the components of a concatenated signal stay together up to the termination
point, it has only an impact on the edge SDH-LSRs.
7. Payload type:
As mentioned earlier different types of information may be transported inside a
VC-X. Making a distinction between the different payload types is not relevant
inside the network. For instance, a cross-connect is simply switching VC-Xs
without looking at the content. However, this distinction is important for end-
systems (edge SDH-LSRs) that have to ônegotiateö a common view. This is why the
payload type is included in this specification. This payload type must be
transported transparently by intermediate SDH-LSRs.
The POH gives some clues about the payload type but this is not always
sufficient. For instance, a VC-3 is able to transport either a 44 736 kbit/s
asynchronous signal, or a 34 368 kbit/s asynchronous signal, or a 34 368 kbit/s
bit synchronous signal or a 34 368 kbit/s byte synchronous signal. The
distinction is not coded in the POH overhead.
In order to simplify and clarify the identification of the payload type, we
propose to explicitly code each payload type according to the following table.
The payload type being coded on 8 bits for instance.
C2 byte V5 bits 5-7
Value Payload type HEX coding bit coding
------------------------------------------------------------------------------
0 Unequipped or supervisory-unequipped 00 000
1 Equipped - non-specific 01 001
2 TUG structure 02
3 Locked TU-n 03
4 Asynchronous mapping of 139 264 kbit/s 12
5 Asynchronous mapping of 44 736 kbit/s 04
6 Asynchronous mapping of 34 368 kbit/s 04
7 Bit synchronous mapping of 34 368 kbit/s
8 Byte synchronous mapping of 34 368 kbit/s
9 Asynchronous mapping of 6312 kbit/s 010
10 Bit synchronous mapping of 6312 kbit/s 011
11 Byte synchronous mapping of 6312 kbit/s 100
12 Asynchronous mapping of 2048 kbit/s 010
13 Byte synchronous mapping of 2048 kbit/s 100
14 Byte synchronous mapping of 31 * 64 kbit/s 100
15 Asynchronous mapping of 1544 kbit/s 010
16 Bit synchronous mapping of 1544 kbit/s 011
17 Byte synchronous mapping of 1544 kbit/s 100
18 Same as 15 but converted in a VC-12 010
19 Same as 16 but converted in a VC-12 011
20 Same as 17 but converted in a VC-12 100
21 ATM mapping 13
22 MAN (DQDB) mapping 14
23 FDDI mapping 15 110
24 Test signal, O.181 specific mapping FE 111
25 VC-AIS FF
26 LLC mapping (to be detailed in next version)
27 Other
Other reserved for future use
This coding is sometimes redundant with the signal identification. For instance
for a VC-11, we know that the bandwidth is 1544 kbit/s, so we simply need to
make a distinction between asynchronous, bit synchronous and byte synchronous
mapping. However, it can help to clarify the payload identification.
Note also that a VC-11 could be converted to a VC-12 for transport by a TU-12.
This conversion is transparent for the intermediate SDH-LSRs, everything appears
such as if the TU-12 transports a regular VC-12. Only edge SDH-LSRs need to know
that it corresponds to a VC-11 and not a VC-12. The distinction is made by the
payload type (see codes 18 to 20).
7.1 Optional extension of a multiplex entry notation and coding:
We could extend the previous multiplex entry notation to cover the payload
identification:
(S, U, K, L, M, P) or S.U.K.L.M.P
Where P denotes the payload value defined before. It results that a multiplex
entry name can now be coded on 4 bytes: 3 bytes for the S.U.K.L.M and one byte
for the payload type. A multiplex entry name now identifies the type of signal,
its exact position and its payload. In case of multiplex based labeling, one
could derive useful information by just looking at the label.
8. Label stacking and LSP tunneling:
If a unstructured high-order LSP is established between two border nodes, these
two nodes should be able to further structure the content of this high-order LSP
(e.g. a VC-4), by defining low-order LSPs (e.g. VC-12s).
>From the MPLS point of view, the low-order LSPs are considered as being
transported through the high-order LSP. This high-order LSP is acting such as a
tunnel.
No new signaling information element is needed to support this facility, since
each multiplex entry name ([label]) refers to the structure in which it is
included. In other words, by identifying the low-order signal, we identify the
high-order signal as well. Note also, that when a signal is defined between two
nodes, it determines a part of the line structure.
For instance, if the first LSP established between two nodes in a network
defines a VC-11 in a VC-3 in one STM-1, it implies that the overall structure of
the STM-1 is fixed along that path. It is up to the SDH-LSRs to determine if
they want to accept such a multiplex.
9. Exchange of signaling and routing messages over SDH:
Two solutions are possible to exchange routing and signaling messages between
two neighbor SDH-LSRs, either out-of-band or in-band.
The out-of-band solution requires a separate network to be established and
maintained, it is not discussed further in this document.
The in-band solution can be implemented in three different ways: either by using
some unused byte(s) in the section overhead; or by using the Data Communication
Channel (D4 to D12 bytes) at 576 kb/s; or by tunneling signaling and routing
messages in some existing protocol transported in the section overhead.
For all cases, it is clear that the Regenerator Section Overhead (RSO) should be
left untouched for evident transparency reasons. A Path Overhead cannot be used
neither since it is end-to-end (at the SDH level).
For the first solution, some unused bytes of the Multiplex Section Overhead
could be used. A single byte of an STM-1 signal provides a 64 Kb/s channel and
is suitable to transport routing and (MPLS) signaling between two SDH-LSR.
However, we are touching the SDH overhead.
The second solution assume that some signaling and routing protocol multiplexing
is allowed in the Data Communication Channel (DCC). Such a multiplexing protocol
could allow making a distinction between MPLS signaling, routing protocols and
existing SDH protocols (to check).
The third solution consists in tunneling or piggybacking messages in an existing
DCC protocol, or in the Multiplexer Section Protection (MSP) switching protocol,
etc. These solutions are more transparent since they avoid deploying a
multiplexing (encapsulation) protocol.
This section will be further detailed in the next version of the draft.
10. Interconnection of different STM-Ns:
SDH is designed to transport a large variety of signals, however different
structures can be used for the transport of Virtual Containers. An SDH-LSR may
allow interconnecting two STM-Ns having different structures. Interconnection
may happen:
- At the VC-3 level with C-3 payload.
- At the TUG-2 level.
- At the VC-11 level.
Possible interconnections are defined in G.707 section 6.4 (see also figure 6-
9). Interconnection may be useful if an incoming interface of a cross-connect is
structured in a different way of its outgoing interface.
For instance, if an incoming STM-1 interface is structured in three VC-3s and
that the outgoing interface to which a VC-3 should be forwarded is structured in
one single VC-4 containing three TUG-3s, the VC-3 cannot be forwarded if
interconnection is not supported.
It results that the multiplex position that is defined between a source border
SDH-LSR and the first intermediate SDH-LSR, may differ from a multiplex position
defined between two other SDH-LSRs for the same type of signal.
11. Impact on routing protocols (SDH routing):
As explained in the previous section, the establishment of an LSP could be
blocked somewhere in a cloud due to incompatibilities between multiplexes. In
addition, some of these incompatibilities may be solved when interconnection is
available at an SDH-LSR.
It results that in order to take the right routing decision, a routing protocol
should know the multiplex table already allocated on each interface, and the SDH
capabilities (interconnection, conversion, concatenation, etc) of each SDH-LSR.
A link state routing protocol is thus required with a constraint based routing
algorithm. The signaling protocol should also be able follow a source route, of
course.
Two possible candidates for routing are of course OSPF and IS-IS, separate
documents will describe extensions to OSPF and IS-IS to transport specific SDH
routing information needed by the constraint-based routing algorithms.
The routing algorithm can be rather complex since the problem is not only to
find a path that satisfies the bandwidth (signal), but also a path that has
suitable multiplexes to transport this signal.
Another problem arises from the fact that the first LSP open through a network
will impose the overall structure of each multiplex along the path. This has an
impact on the future signals that it will be possible to transport. The way that
this first LSP is positioned in the multiplex should be carefully chosen.
12. MPLS-SDH profiles:
It is reasonable to think that two SDH nodes from different manufacturers will
have different cross-connecting and multiplexing capabilities, since it is
highly dependent on the hardware. For instance, traditional equipment are mainly
DXC (Digital Cross-Connect) 4/4 (VC-4 switching only) and DXC 4/3/1 (VC-4, VC-3
and VC-12 switching).
It results that some profiles could be defined, specifying for instance a
minimal set of capabilities:
- The high and low order signals supported for switching.
- The set of SDH capabilities to be supported:
- Concatenation + type.
- Interconnection capabilities.
- Conversion capabilities.
- Etc.
- The signaling protocol to use.
- The routing protocol to use with extensions.
- Etc.
13. Security Considerations
Security considerations are not discussed in this version of the document.
14. Acknowledgments
The author would like to thank Andrea Bernardini, Paolo Casaschi, Pedro Falcao,
Bernard Heens, Bruno Meuris, Michael Moelants, Gzim Ocakoglu and Jose Miguel
Santos for their valuable help and comments on this work (names sorted by
alphabetical order).
15. Authors' Addresses
Eric Mannie
GTS Network Services
RDI Department, Core Network Technology Group
Terhulpsesteenweg, 6A
1560 Hoeilaart
Belgium
E-mail: eric.mannie@gtsgroup.com
Tel: +32-2-658.56.52
16. References
[1] Rosen, E., Viswanathan, A., and Callon, R., "Multiprotocol Label
Switching Architecture", Work in Progress, April 1999.
[2] Callon, R., Doolan, P., Feldman, N., Fredette, A., Swallow, G.,
Viswanathan, A., "A Framework for Multiprotocol Label Switching",
Work in Progress, November 1997.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", RFC 2119, BCP 14, March 1997.
[4] Postel, J., "Internet Control Message Protocol", RFC 792,
September 1981.
[5] Mogul, J. and Deering S., "Path MTU Discovery", RFC 1191,
November 1990.
[6] Katz, D., "IP Router Alert Option", RFC 2113, February 1997.
[7] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", RFC
1661, STD 51, July 1994.
[8] Conta, A. and Deering, S., "Internet Control Message Protocol
(ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification",
RFC 1885, December 1995.
[9] McCann, J., Deering, S. and Mogul, J., "Path MTU Discovery for IP
version 6", RFC 1981, August 1996.
[10] Davie, B., Lawrence, J., McCloghrie, K., Rekhter, Y., Rosen, E.
and Swallow G., "MPLS Using LDP and ATM VC Switching", Work in
Progress, April 1999.
[11] McCloghrie, K. and M. Rose, "Management Information Base for
Network Management of TCP/IP-based internets - MIB-II", STD 17,
RFC 1213, March 1991.
[12] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB",
RFC 2233, November 1997.
[13] G.707, "Network node interface for the synchronous digital hierarchy
(SDH)", ITU-T, 3/96.
Annex A û CR-LDP for SDH Control
This annex describes how CR-LDP may be used to establish SDH-LSPs. It will be
filled in the next version of this specification.
Annex B û TE-RSVP for SDH Control
This annex will be filled in the next version of this specification.