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.